Copy the one in libxl, remove the irrelevant bits about libxl. Replace
libxl with xl where appropriate.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
When calling configure for qemu provide the local pkg-config directory
in order to let the configure process find the libxenctrl version.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Instead of using the downloaded git tree as target directory for the
qemu build create a dedicated directory for that purpose.
This way it is possible to use the same source directory of qemu to
configure and build qemu upstream in a stubdom environment in future.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
When configuring the build of qemu the configure script is building
various test programs to determine the exact version of libxencontrol.
Instead of a try and error approach needing updates for nearly each
new version of Xen just provide xencontrol.pc to be used via
pkg-config.
In the end we need two different variants of that file: one for the
target system where eventually someone wants to build qemu, and one
for the local system to be used for building qemu as part of the Xen
build process.
The local variant is created in a dedicated directory in order to be
able to collect more pkg-config files used for building tools there.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
A stubdom app using xenctrl.h must use the latest interface version of
Xen in order to avoid compatibility issues. Add the related config
item to the stubdom config files where needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Some libc headers don't have O_CLOEXEC, we need to take care of it by
defining to 0 (on the ground that such glibc might barf on O_CLOEXEC).
Fixes e7745d8ef5 ("tools/libxendevicemodel: introduce a Linux-specific
implementation")
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
If acpi_map_os_memory has failed, return early with AE_ERROR.
Coverity-ID: 1401601
Coverity-ID: 1401602
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them and
returns a value to the frontend and acts on the function call.
This version of the document covers networking function calls, such as
connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but
the protocol is meant to be easily extended to cover different sets of
calls. Unimplemented commands return ENOTSUP.
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
9pfs is a network filesystem protocol developed for Plan 9. 9pfs is very
simple and describes a series of commands and responses. It is
completely independent from the communication channels, in fact many
clients and servers support multiple channels, usually called
"transports". For example the Linux client supports tcp and unix
sockets, fds, virtio and rdma.
This design document outlines the transport protocol for
9pfs payload.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
We record trace information about the next timeslice when
switching to a different vcpu, but not when continuing to
run the same cpu:
csched2:schedule cpu 9, rq# 1, idle, SMT idle, tickled
csched2:runq_candidate d0v3, 0 vcpus skipped, cpu 9 was tickled
sched_switch prev d32767v9, run for 991.186us
sched_switch next d0v3, was runnable for 2.515us, next slice 10000.0us
sched_switch prev d32767v9 next d0v3 ^^^^^^^^^^^^^^^^^^^^
runstate_change d32767v9 running->runnable
...
csched2:schedule cpu 2, rq# 0, busy, not tickled
csched2:burn_credits d1v5, credit = 9996950, delta = 502913
csched2:runq_candidate d1v5, 0 vcpus skipped, no cpu was tickled
runstate_continue d1v5 running->running
?????????????
This information is quite useful; so add a trace including
that information on the 'continue_running' path as well,
like this:
csched2:schedule cpu 1, rq# 0, busy, not tickled
csched2:burn_credits d0v8, credit = 9998645, delta = 12104
csched2:runq_candidate d0v8, credit = 9998645, 0 vcpus skipped, no cpu was tickled
sched_switch continue d0v8, run for 1125.820us, next slice 9998.645us
runstate_continue d0v8 running->running ^^^^^^^^^^^^^^^^^^^^^
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
When traversing a Credit2 runqueue to select the
best candidate vCPU to be run next, show in the
trace which vCPUs we consider.
A bit verbose, but quite useful, considering that
we may end up looking at, but then discarding, one
of more vCPU. This will help understand which ones
are skipped and why.
Also, add how much credits the chosen vCPU has
(in the TRC_CSCHED2_RUNQ_CANDIDATE record). And,
while there, fix a bug in tools/xentrace/formats
(still in the output of TRC_CSCHED2_RUNQ_CANDIDATE).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
So that they're all close among each other, and
also near to the comment describing the runqueue
organization (which is also moved).
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
There is no reason for having pretty much all of the
functions whose names begin with double underscores
('__') to actually look like that.
In fact, that is misleading and makes the code hard
to read and understand. So, remove the '__'-s.
The only two that we keep are __runq_assign() and
__runq_deassign() (althought they're converted to
single underscore). In fact, in those cases, it is
indeed useful to have those sort of a "raw" variants.
In case of __runq_insert(), which is only called
once, by runq_insert(), merge the two functions.
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
There isn't any particular reason for the accessor helpers
to be macro, so turn them into 'static inline'-s, which are
better.
Note that it is necessary to move the function definitions
below the structure declarations.
No functional change intended.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
A credit reset basically means going through all the
vCPUs of a runqueue and altering their credits, as a
consequence of a 'scheduling epoch' having come to an
end.
Blocked or runnable vCPUs are fine, all the credits
they've spent running so far have been accounted to
them when they were scheduled out.
But if a vCPU is running on a pCPU, when a reset event
occurs (on another pCPU), that does not get properly
accounted. Let's therefore begin to do so, for better
accuracy and fairness.
In fact, after this patch, we see this in a trace:
csched2:schedule cpu 10, rq# 1, busy, not tickled
csched2:burn_credits d1v5, credit = 9998353, delta = 202996
runstate_continue d1v5 running->running
...
csched2:schedule cpu 12, rq# 1, busy, not tickled
csched2:burn_credits d1v6, credit = -1327, delta = 9999544
csched2:reset_credits d0v13, credit_start = 10500000, credit_end = 10500000, mult = 1
csched2:reset_credits d0v14, credit_start = 10500000, credit_end = 10500000, mult = 1
csched2:reset_credits d0v7, credit_start = 10500000, credit_end = 10500000, mult = 1
csched2:burn_credits d1v5, credit = 201805, delta = 9796548
csched2:reset_credits d1v5, credit_start = 201805, credit_end = 10201805, mult = 1
csched2:burn_credits d1v6, credit = -1327, delta = 0
csched2:reset_credits d1v6, credit_start = -1327, credit_end = 9998673, mult = 1
Which shows how d1v5 actually executed for ~9.796 ms,
on pCPU 10, when reset_credit() is executed, on pCPU
12, because of d1v6's credits going below 0.
Without this patch, this 9.796ms are not accounted
to anyone. With this patch, d1v5 is charged for that,
and its credits drop down from 9796548 to 201805.
And this is important, as it means that it will
begin the new epoch with 10201805 credits, instead
of 10500000 (which he would have, before this patch).
Basically, we were forgetting one round of accounting
in epoch x, for the vCPUs that are running at the time
the epoch ends. And this meant favouring a little bit
these same vCPUs, in epoch x+1, providing them with
the chance of execute longer than their fair share.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
In fact, whether or not a pCPU has been tickled, and is
therefore about to re-schedule, is something we look at
and base decisions on in various places.
So, let's make sure that we do that basing on accurate
information.
While there, also tweak a little bit smt_idle_mask_clear()
(used for implementing SMT support), so that it only alter
the relevant cpumask when there is the actual need for this.
(This is only for reduced overhead, behavior remains the
same).
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
When toolstack overrides Intel CPUID leaf 0xa's PMU version with an
invalid value VPMU should not be available to the guest.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
vpmu_enabled() (used by hvm/pv_cpuid() to properly report 0xa leaf
for Intel processors) is based on the value of VPMU_CONTEXT_ALLOCATED
bit. This is problematic:
* For HVM guests VPMU context is allocated lazily, during the first
access to VPMU MSRs. Since the leaf is typically queried before guest
attempts to read or write the MSRs it is likely that CPUID will report
no PMU support
* For PV guests the context is allocated eagerly but only in responce to
guest's XENPMU_init hypercall. There is a chance that the guest will
try to read CPUID before making this hypercall.
This patch introduces VPMU_AVAILABLE flag which is set (subject to vpmu_mode
constraints) during VCPU initialization for both PV and HVM guests. Since
this flag is expected to be managed together with vpmu_count, get/put_vpmu()
are added to simplify code.
vpmu_enabled() (renamed to vpmu_available()) can now use this new flag.
(As a side affect this patch also fixes a race in pvpmu_init() where we
increment vcpu_count in vpmu_initialise() after checking vpmu_mode)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Freeing part of the BSS back for general use proves to be problematic. It is
not accounted for in xen_in_range(), causing errors when constructing the
IOMMU tables, resulting in a failure to boot.
Other smaller issues are that tboot treats the entire BSS as hypervisor data,
creating and checking a MAC of it on S3, and that, by being 1MB in size,
freeing it guarentees to shatter the hypervisor superpage mappings.
This is a stopgap fix to unblock master, while alternatives are discussed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For a transitional period (until we've managed to replace all
underscore prefixed instances), allow both names to co-exist.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current implementation of nested VMX cannot work without HAP.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For a HVM domain, if a vcpu is in the nested guest mode,
__raw_copy_to_guest(), __copy_to_guest() and __copy_field_to_guest()
used by update_runstate_area() and update_secondary_system_time() will
copy data to L2 guest rather than the L1 guest.
This commit temporally clears the nested guest flag before all guest
copies in update_runstate_area() and update_secondary_system_time(),
and restores the flag after those guest copy operations.
The flag clear/restore is combined with the existing
smap_policy_change() which is renamed to update_guest_memory_policy().
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
As some users have suggested, elaborate the usage of RMRR specification
on the command line, and provide a usage example.
Also, always treat the specified page numbers as hexadecimal values.
Signed-off-by: Venu Busireddy <venu.busireddy@oracle.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
That is to say, don't support a domain assigns a device to itself or detachs
a device from itself.
Signed-off-by: Chao Gao <chao.gao@intel.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The default dom0_mem is 128M which is not sufficient to boot a Ubuntu
based Dom0. It is not clear what a better default value could be.
Instead, loudly warn the user when dom0_mem is unspecified and wait 3
secs. Then use 512M.
Update the docs to specify that dom0_mem is required on ARM. (The
current xen-command-line document does not actually reflect the current
behavior of dom0_mem on ARM correctly.)
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
c/s b4cd59fe "x86: reorder .data and .init when linking" had an unintended
side effect, where xen_in_range() and the tboot S3 MAC were no longer correct.
In practice, it means that Xen's .data section is excluded from consideration,
which means:
1) Default IOMMU construction for the hardware domain could create mappings.
2) .data isn't included in the tboot MAC checked on resume from S3.
Adjust the comments and virtual address anchors used to define the regions.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
As a memory report can now be triggered via XS_CONTROL support via
command line and signal handler is no longer needed. Remove it.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Add a XS_CONTROL command to xenstored for doing a talloc report to a
file. Right now this is supported by specifying a command line option
when starting xenstored and sending a signal to the daemon to trigger
the report.
To dump the report to the standard log file call:
xenstore-control memreport
To dump the report to a new file call:
xenstore-control memreport <file>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Today Xenstore supports logging only if specified at start of the
Xenstore daemon. As it can't be disabled during runtime it is not
recommended to start xenstored with logging enabled.
Add support for switching logging on and off at runtime and to
specify a (new) logfile. This is done via the XS_CONTROL wire command
which can be sent with xenstore-control.
To switch logging on just use:
xenstore-control log on
To switch it off again:
xenstore-control log off
To specify a (new) logfile:
xenstore-control logfile <file>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
The Xenstore protocol supports the XS_CONTROL command for triggering
various actions in the Xenstore daemon. Enhance that support by using
a command table and adding a help function.
Support multiple control commands in the associated xenstore-control
program used to issue XS_CONTROL commands.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Move the XS_CONTROL handling of xenstored to a new source file
xenstored_control.c.
In order to avoid making get_string() in xenstored_core.c globally
visible use strlen() instead, which is save in this context due to
xs_count_strings() before returned a value > 1.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
In preparation to support other than pure debug functionality via the
Xenstore XS_DEBUG wire command rename it to XS_CONTROL and make
XS_DEBUG an alias of it.
Add an alias xs_control_command for the associated xs_debug_command,
too.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
After splitting out all the meaty bits, xl_cmdimpl.c doesn't contain
much. Merge the rest into xl.c and delete the file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Include COLO / Remus code because they are built on top of the existing
migration protocol.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add some function declarations to xl.h because they are now needed in
multiple files.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Including create, reboot, shutdown, pause, unpause and destroy.
Lift a bunch of core data structures and function declarations to xl.h
because they are needed in both xl_cmdimpl.c and xl_vmcontrol.c.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich
Wei Liu
Juergen Gross
Anthony PERARD
Olaf Hering
Stefano Stabellini
Dario Faggioli
Boris Ostrovsky
Andrew Cooper
Haozhong Zhang
Venu Busireddy
Chao Gao
Stefano Stabellini
Roger Pau Monne