Despite this array living in an __init function, having such be an
automatic variable is rather inefficient in terms of generated code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Wang2 <wei.wang2@amd.com>
Supports the xl subcommand sched-sedf.
The man page is only a minimal version (copy from xm man page without
examples). BTW: the xm man page seems not to be in sync with xm sched-sedf -h
regarding the time units. I used milliseconds in the xl implementation.
Only minimal semantical checks of parameters.
Signed-off-by: juergen.gross@ts.fujitsu.com
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Just a typo...
Signed-off-by: juergen.gross@ts.fujitsu.com
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Supports the xl subcommand sched-credit2.
Signed-off-by: juergen.gross@ts.fujitsu.com
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Adds cpupool awareness to output of xl sched-credit. Output can now be
restricted to a specific cpupool. The domains are printed for each cpupool
seperately.
The loop over cpupools and domains is seperated from the main command
implementation to be able to support other schedulers as well.
Signed-off-by: juergen.gross@ts.fujitsu.com
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
The help text of xl sched-credit supported long options. Neither the man page
nor the implementation did.
Signed-off-by: juergen.gross@ts.fujitsu.com
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
insufficient quoting between "tap-ctl list" and xend/server/BlktapController.py
BlktapController splits the output into lines using \n, then each line
at each space, and finally each of these 'words' at the '=', which
fails if the filename contains spaces.
As a quick work-around, the attached patch fixes the problem for me. That is,
until tap-ctl changes it's output format.
A more permanent solution would be to add proper quoting / escaping to tap-ctl
and un-quoting / de-escaping to BlktapController.py
Signed-off-by: Philipp Hahn <hahn@univention.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
There is currently no code in the kernel to trigger autoload of the
evtchn or gntdev drivers. Load them manually during xencommons start.
Handle both pvops and xenlinux module names.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently xencommons prints an error that /proc/xen/capabilities does
not exist when started on a non-xen kernel.
Update the xencommons script to run only when needed:
- do not run if /proc/xen does not exist
- check if /proc/xen/capabilities exists before doing the grep for dom0
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The notify offset and event channels are both unsigned variables, so
testing for >= 0 will not correctly detect the use of -1 to indicate
the field is unused. Remove the useless comparison and replace with
correct range checks or comparisons to -1.
Reported-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
p2m_mem_paging_prep ensures that an mfn is backing the paged-out gfn, and
transitions to the next state in the paging state machine for that page.
Foreign mappings of the gfn will now succeed. This is the key idea, as
it allows the pager to now map the gfn and fill in its contents.
Unfortunately, it also allows any other foreign mapper to map the gfn and read
its contents. This is particularly dangerous when the populate is launched
by a foreign mapper in the first place, which will be actively retrying the
map operation and might race with the pager. Qemu-dm being a prime example.
Fix the race by allowing a buffer to be optionally passed in the prep
operation, and having the hypervisor memcpy from that buffer into the newly
prepped page before promoting the gfn type.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
This command works in two steps. First, a fd is sent to QEMU through the QMP
socket. And then, the second command "migrate" use the fd previously sent to
ask QEMU to save its states.
This comes with an alternative qmp_send function that can send a fd.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
This patch prepares for the next patch, that will introduce an
alternative send function.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Jackson <ian.jackson.citrix.com>
Committed-by: Ian Jackson <ian.jackson.citrix.com>
Since libxc is re-entrant, there is no need for the OCaml bindings to
prevent more than one thread from entering libxc concurrently.
Previously, the OCaml bindings had prevented re-entrancy by not using
caml_{enter,leave}_blocking_section in the C stubs. The absence of
these calls meant that the global lock remained held during
hypercalls. This caused multi-threaded applications to completely lock
up during long-running hypercalls.
Calls to these functions were present but commented out in the OCaml
bindings some years ago when libxc was not fully re-entrant.
Instead, we now do call caml_{enter,leave}_blocking_section in all the
places it used to be commented out, meaning that the global lock is
released during those hypercalls. We also no longer assert the
XC_OPENFLAG_NON_REENTRANT flag when calling xc_interface_open because
the caller no longer does re-entrancy prevention at those places.
This patch has now gone through a XenRT nightly test; no problems were
observed.
Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Check that the valid mfn is the one we are mapping, not the
mfn of the page table of the foreign domain.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
The nested hvm code maps pages of the guest hvm. These maps live beyond
a hypervisor entry/exit pair, and thus their liveness cannot be ensured
with get_gfn/put_gfn critical sections. Ensure their liveness by
increasing the page ref count, instead.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
This conversion is a trivial invocation of virt_to_mfn in 64 bits.
In 32 bits it uses the linear_map.
Signed-off-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Signed-off-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
Largely as a result of the continuing resistance of Linux maintainers
to accept a microcode loading patch for pv-ops Xen kernels, this
follows the suggested route and provides a means to load microcode
updates without the assistance of Dom0, thus also addressing eventual
problems in the hardware much earlier.
This leverages the fact that via the multiboot protocol another blob
of data can be easily added in the form of just an extra module. Since
microcode data cannot reliably be recognized by looking at the
provided data, this requires (in the non-EFI case) the use of a
command line parameter ("ucode=<number>") to identify which of the
modules is to be parsed for an eventual microcode update (in the EFI
case the module is being identified in the config file, and hence the
command line argument, if given, will be ignored).
This required to adjust the XSM module determination logic accordingly.
The format of the data to be provided is the raw binary blob already
used for AMD CPUs, and the output of the intel-microcode2ucode utility
for the Intel case (either the per-(family,model,stepping) file or -
to make things easier for distro-s integration-wise - simply the
concatenation of all of them).
In order to not convert the spin_lock() in microcode_update_cpu() (and
then obviously also all other uses on microcode_mutex) to
spin_lock_irqsave() (which would be undesirable for the hypercall
context in which the function also runs), the boot time handling gets
done using a tasklet (instead of using on_selected_cpus()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
- memory was leaked on a CPU offline/online cycle (including S3)
- memory was leaked on AMD systems when microcode_update() ran a 2nd
time with the same data that was used on the first run
- microcode never got restored on APs during S3 resume (or post-boot
onlining of a CPU that was also online when microcode_update() first
ran [in the event the prior microcode update got lost intermediately,
which supposedly shouldn't happen]); this will still be the case when
no other online CPU has an identical signature (which however is now
consistent with bringing up such a CPU the very first time)
- resume was unimplemented in the AMD case
- there was a race between microcode_update_cpu() and
microcode_resume_cpu()
This also moves vendor specific type declarations to the vendor source
file and sets the stage for boot time microcode loading (i.e. without
Dom0 involvement).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
At restore time, the file descriptor opened on the migration state file is
still open in the device model. Let's apply FD_CLOEXEC to it.
This patch provides libxl_fd_set_cloexec to users of libxl, instead of keeping
this function internal.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The test system problems which prompted 24233:a9c67c2daf4b (itself a
tiny partial revert of 24184:4ecd3615e726 / 24186:7aa5838499d1) have
now been resolved, we think. So revert 24233.
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>