Document the multi-queue/ring feature in terms of XenStore keys to be written
by the backend and by the frontend.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Previously, xenconsoled's daemonize function would do nothing if its
parent process is init (as it is under systemd but not sysv init).
This is confusing. Instead, always daemonize when asked to, but use the
"interactive" switch when running from the systemd service.
Because a pidfile is only written when daemonizing, drop the pidfile
parameters from the service file (systemd keeps track of the pids
anyway).
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In fact, right now, failing at destroying a cpupool is just
not reported to the user in any explicit way.
Let's log an error, as it is customary for xl in these cases.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Rearange the case when we check the new number of vCPUs
against the number of host pCPUs not to use rc for internal
error reporting. In fact:
- rc was at risk of being used uninitialised;
- rc should only be used for holding libxl error codes.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
In 5b725e56 (xl: improve return and exit codes of vcpu related
functions), the return value of libxl_cpu_bitmap_alloc was not stored in
rc anymore. Yet the subsequent fprintf still used that.
Reinstate the original implementation, that is, to store return value of
libxl_cpu_bitmap_alloc in rc before using rc.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
It is __read_mostly, so repeatedly writing to it is suboptiomal. As the
MTRRs have already been set up, nothing good will come from its value
changing across CPUs.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Using new _ASM_BUGFRAME* internals.
A side effect of complicating the ASM statements is that GCC now chooses to
out-of-line the stub functions, resulting in identical copies being present in
all translation units. As with the stac()/clac() stubs, force them always
inline.
No functional change, other than the failure cases, which now produce a
far more clear error message.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
To allow bug frames can be created inside existing asm() statements. In
order to do so, the current bugframe positional parameters are altered
to be named parameters, to avoid interactions with the parameters of the
existing asm() statement.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Combine the almost identical vm_launch_fail() and vm_resume_fail() into a
single vmx_vmentry_failure().
Re-save all GPRs so that domain_crash() prints the real register values,
rather than the stack frame of the vmx_vmentry_failure() call.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
To make it possible to tell apart the static symbols in files built a
second time for compat guest support, arrange for their source file
names to be prefixed by a suitable path. We can't do this without
explicit .file directives, since gcc has always been stripping paths
from file names handed to the internally generated .file directive.
However, we can leverage __FILE__ if we make sure the second instance
gets compiled out of other than the very directory the wrapper sits in.
Where suitable, remove the long redundant explicit inclusions of
xen/config.h at once.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This requires adjustments to the tool generating the symbol table and
its as well as nm's invocation.
Note: Not warning about duplicate symbols in the EFI case for now, as
a binutils bug causes misnamed file name entries to appear in EFI
binaries' symbol tables when the file name is longer than 18 chars.
(Not doing so also avoids other duplicates getting printed twice.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Turning parsing related functions exit codes towards using the
EXIT_[SUCCESS|FAILURE] constants, instead of instead of arbitrary numbers
or libxl return codes.
- for main_*: arbitrary -> EXIT_SUCCESS|EXIT_FAILURE.
- for internal fucntion: arbitrary -> 0/1.
Don't touch parse_config_data() which is big enough to deserve its own patch.
Signed-off-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Turning cpupools related functions exit codes towards using the
EXIT_[SUCCESS|FAILURE] constants, instead of instead of arbitrary numbers
or libxl return codes.
Signed-off-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Turning scheduling related functions exit codes towards using the
EXIT_[SUCCESS|FAILURE] constants, instead of instead of arbitrary numbers
or libxl return codes.
- for main_*: arbitrary -> EXIT_SUCCESS|EXIT_FAILURE.
- for internal fucntion: arbitrary -> 0/1.
Signed-off-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Turning main() function exit codes towards using the EXIT_[SUCCESS|FAILURE]
constants, instead of instead of arbitrary numbers or libxl return codes.
Also includes a document comment in xl.h stating xl process should always
return EXIT_FOO and main_* can be treated as main() as if they are returning
a process exit status and not a function return value)
Signed-off-by: Harmandeep Kaur <write.harmandeep@gmail.com>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
xendomains will manage guests behind libvirts back:
- libvirt starts a guest
- that guest can be "managed" by libvirt and xl at the same time
- when xendomains runs on shutdown it will save the guest using xl
libvirt does not know about this
- when xendomains runs on boot it will restore the saved guest using xl
libvirt does not know about this, it will just fail to manage the
restored guest
To prevent xendomains from interfering with libvirt add a Conflicts= to
xendomains.service. It will cause libvirt to be stopped if xendomains is
started manually with 'systemctl start'.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
That directory is used to store guest memory dump which contains
sensitive information.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
def_getopt would print a message to stderr, but blunder on anyway.
Sadly this is probably not a backport candidate.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
This avoids a long running operation when destroying a domain with a
large PoD cache.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
In fact, when waking up a vCPU, __runq_tickle() is called
to allow the new vCPU to run on a pCPU (which one, depends
on the relationship between the priority of the new vCPU,
and the ones of the vCPUs that are already running).
If there is no idle processor on which the new vCPU can
run (e.g., because of pinning/affinity), we try to migrate
away the vCPU that is currently running on the new vCPU's
processor (i.e., the processor on which the vCPU is waking
up).
Now, trying to migrate a vCPU has the effect of pushing it
through a
running --> offline --> runnable
transition, which, in turn, has the following negative
effects:
1) Credit1 counts that as a wakeup, and it BOOSTs the
vCPU, even if it is a CPU-bound one, which wouldn't
normally have deserved boosting. This can prevent
legit IO-bound vCPUs to get ahold of the processor
until such spurious boosting expires, hurting the
performance!
2) since the vCPU is fails the vcpu_runnable() test
(within the call to csched_schedule() that follows
the wakeup, as a consequence of tickling) the
scheduling rate-limiting mechanism is also fooled,
i.e., the context switch happens even if less than
the minimum execution amount of time passed.
In particular, 1) has been reported to cause the following
issue:
* VM-IO: 1-vCPU pinned to a pCPU, running netperf
* VM-CPU: 1-vCPU pinned the the same pCPU, running a busy
CPU loop
==> Only VM-I/O: throughput is 806.64 Mbps
==> VM-I/O + VM-CPU: throughput is 166.50 Mbps
This patch solves (for the above scenario) the problem
by checking whether or not it makes sense to try to
migrate away the vCPU currently running on the processor.
In fact, if there aren't idle processors where such a vCPU
can execute. attempting the migration is just futile
(harmful, actually!).
With this patch, in the above configuration, results are:
==> Only VM-I/O: throughput is 807.18 Mbps
==> VM-I/O + VM-CPU: throughput is 731.66 Mbps
Reported-by: Kun Suo <ksuo@uccs.edu>
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Tested-by: Kun Suo <ksuo@uccs.edu>
Acked-by: George Dunlap <george.dunlap@citrix.com>
Rather than issuing a (mostly) useless separate message, rely on
domain_crash() providing enough data, and leverage the line number
information it prints.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Recent ld warns about libxenlight.so's dependency libraries not being
available, which can be easily avoided by not just passing the raw
library name on ld's command line.
In the course of checking how things fit together (I originally
suspected the warning to come from the linking of xl) I also noticed a
stray L in SHLIB_libxenguest, which gets removed at once.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
PoD guests need to balloon at least as far as required by PoD, or risk
crashing. Currently they don't necessarily know what the right value
is, because our memory accounting is (at the very least) confusing.
Apply the memory limit fudge factor to the in-hypervisor PoD memory
target, too. This will increase the size of the guest's PoD cache by
the fudge factor LIBXL_MAXMEM_CONSTANT (currently 1Mby). This ensures
that even with a slightly-off balloon driver, the guest will be
stable even under memory pressure.
There are two call sites of xc_domain_set_pod_target that need fixing:
The one in libxl_set_memory_target is straightforward.
The one in xc_hvm_build_x86.c:setup_guest is more awkward. Simply
setting the PoD target differently does not work because the various
amounts of memory during domain construction no longer match up.
Instead, we adjust the guest memory target in xenstore (but only for
PoD guests).
This introduces a 1Mby discrepancy between the balloon target of a PoD
guest at boot, and the target set by an apparently-equivalent `xl
mem-set' (or similar) later. This approach is low-risk for a security
fix but we need to fix this up properly in xen.git#staging and
probably also in stable trees.
This is XSA-153.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
(cherry picked from commit 56fb5fd623)
Some of the sub-ops are acessible to all guests, and hence should be
rate-limited. In the xenoprof case, just like for XSA-146, include them
only in debug builds. Since the vPMU code is rather new, allow them to
be always present, but downgrade them to (rate limited) guest messages.
This is CVE-2015-7971 / XSA-152.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
This was overlooked in fb442e2171 ("x86_64: allow more vCPU-s per
guest").
This is CVE-2015-7969 / XSA-151.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ian Campbell <ian.campbell@citrix.com>
Based on the contents of a guests physical address space,
p2m_pod_emergency_sweep() could degrade into a linear memcmp() from 0 to
max_gfn, which runs non-preemptibly.
As p2m_pod_emergency_sweep() runs behind the scenes in a number of contexts,
making it preemptible is not feasible.
Instead, a different approach is taken. Recently-populated pages are eagerly
checked for reclaimation, which amortises the p2m_pod_emergency_sweep()
operation across each p2m_pod_demand_populate() operation.
Note that in the case that a 2M superpage can't be reclaimed as a superpage,
it is shattered if 4K pages of zeros can be reclaimed. This is unfortunate
but matches the previous behaviour, and is required to avoid regressions
(domain crash from PoD exhaustion) with VMs configured close to the limit.
This is CVE-2015-7970 / XSA-150.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
When optional super page support got added (commit bd1cd81d64 "x86: PV
support for hugepages"), two adjustments were missed: mod_l2_entry()
needs to consider the PSE and RW bits when deciding whether to use the
fast path, and the PSE bit must not be removed from L2_DISALLOW_MASK
unconditionally.
This is CVE-2015-7835 / XSA-148.
Reported-by: "栾尚聪(好风)" <shangcong.lsc@alibaba-inc.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Primarily this means XENMEM_decrease_reservation from a toolstack
domain.
Unlike x86 we have no requirement right now to queue such pages onto
a separate list, if we hit this race then the other code has already
fully accepted responsibility for freeing this page and therefore
there is no more for relinquish_memory to do.
This is CVE-2015-7814 / XSA-147.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
These are guest accessible and should therefore be rate-limited.
Moreover, include them only in debug builds.
This is CVE-2015-7813 / XSA-146.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Multicall for ARM has been supported since commit f0dbdc6 "xen: arm: fully
implement multicall interface.". Although, if an hypercall in multicall
requires preemption, it will crash the host:
(XEN) Xen BUG at domain.c:347
(XEN) ----[ Xen-4.7-unstable arm64 debug=y Tainted: C ]----
[...]
(XEN) Xen call trace:
(XEN) [<00000000002420cc>] hypercall_create_continuation+0x64/0x380 (PC)
(XEN) [<0000000000217274>] do_memory_op+0x1b00/0x2334 (LR)
(XEN) [<0000000000250d2c>] do_multicall_call+0x114/0x124
(XEN) [<0000000000217ff0>] do_multicall+0x17c/0x23c
(XEN) [<000000000024f97c>] do_trap_hypercall+0x90/0x12c
(XEN) [<0000000000251ca8>] do_trap_hypervisor+0xd2c/0x1ba4
(XEN) [<00000000002582cc>] guest_sync+0x88/0xb8
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 5:
(XEN) Xen BUG at domain.c:347
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
Looking to the code, the support of multicall looks valid to me, as we only
need to fill call.args[...]. So drop the BUG();
This is CVE-2015-7812 / XSA-145.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The variable "svc" is declared twice within rt_dom_cntl. However, the
top declaration could be re-used avoiding re-declaring another time the
variable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
The variable "cur" is declared twice within "cur". However the top
declaration could be re-used avoiding re-declaring another time the
variable.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The variable "d" is declared multiple times within do_memory_op.
The subsequent declaration are not useful because the top one is never
used. So drop them.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The variable "frame" is declared twice within the function
__gntab_map_grant_ref. This makes the code quite confusing to read.
The second definition is not useful as the first one is never used
until then. So drop it.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The variable "d" is defined twice. However, the second one is not
necessary as the vCPU as already been deduced from the first "d".
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
No need to generate xen/lowlevel/xl/_pyxl_types.{h,c}, following c/s
598e97f "tools/python: remove broken xl binding"
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Somehow I managed to drop the HVM dependency from v2 to v3 of what
became commit 5c23c760a8 ("x86/HVM: correct page dirty marking in
hvm_map_guest_frame_rw()"), obviously breaking migration of PV guests.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
The current domain and the domain pointed by the variable "d" are not
the same.
However, when it's not possible to get a reference on the page, the
target domain ID is not printed. This makes the message difficult to
understand.
Improve the message by printing the target domain ID.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Direct mapped domain needs to retrieve the exact same underlying
physical page when the region is re-populated.
Currently, when the memory reservation for this domain is decreased, the
request is just ignored and the page stayed mapped in the P2M. However,
this make more difficult to spot issue when the domain has not yet mapped
foreign page but trying to access the region.
What we really care for direct mapped domain is to not give back the
page to the allocator. So we can re-enable to direct mapped when the guest
memory region is re-populated.
The rest of the process to remove a page can be safely done. This
also ensures us to stay close to the normal domain memory handling.
At the same time, drop the trailing whitespaces around the code
modified.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Bob Liu
Ross Lagerwall
Dario Faggioli
Wei Liu
Ian Campbell
Andrew Cooper
Jan Beulich
Harmandeep Kaur
Quan Xu
Olaf Hering
Julien Grall
Ian Jackson