On ARM guest OSes are started with MMU and Caches disables (as they are on
native) however caching is enabled in the domain running the builder and
therefore we must flush the cache as we load the blobs, otherwise when the
guest starts running it may not see them. The dom0 build in the hypervisor has
the same requirements and already does the right thing.
The mechanism for performing a cache flush from userspace is OS specific, so
implement this as a new osdep hook:
- On 32-bit ARM Linux provides a system call to flush the cache.
- On 64-bit ARM Linux the processor is configured to allow cache flushes
directly from userspace.
- Non-Linux platforms will need to provide their own implementation. If
similar mechanisms are not available then a new privcmd ioctl should be a
suitable alternative.
No cache maintenance is required on x86, so provide a stub for all non-Linux
platforms which returns success on x86 only and log an error otherwise.
This fixes guest building on Xgene which has a very large L3 cache and so is
particularly susceptible to this problem. It has also been observed
sporadically on midway.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Andre Przywara <andre.przywara@calxeda.com>
Cc: Pranavkumar Sawargaonkar <psawargaonkar@apm.com>
Cc: Anup Patel <apatel@apm.com>
Currently we check the pty path received from xenstore with access(); if
it indicates that the pty is not accessible, we loop around and wait for
a new path to appear in xenstore.
This has several issues:
* If a path has been written to xenstore, it can be assumed that that
pty should already be accessible to xenconsole, and hence any error
that occurs while trying to open it should be fatal and not ignored
* If access() indicates no access to the pty, the memory allocated for
the path is leaked when going around the loop again
* The accessibility of the pty could change between the access() and
open() calls, leading to a TOCTOU race (this is what Coverity is
complaining about).
By removing the explicit access() check and just erroring out whenever
open() fails, we fix all these issues.
Coverity-ID: 1056047
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Coverity ID: 1055996 1056002
Cache the xs_daemon_socket{,_ro}() strings to save pointlessly
re-snprintf()'ing the same path, and add explicit size checks against
addr.sun_path before strcpy()'ing into it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Both src[i].size and delta are unsigned, so checking their difference
for being less than 0 doesn't work.
Coverity-ID: 1055615
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
While at it, tidy up the function; there's no point in allocating more
than the amount of domains actually returned by xc_domain_getinfolist
(barring the caveat described in the newly-added comment)
Coverity-ID: 1055888
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Ocaml has a heap lock which must be held whenever ocaml code is running. Ocaml
usually drops this lock when it enters a potentially blocking low-level
function, such as writing to a file. Libxl has its own lock, which it may
acquire when being called.
Things get interesting when libxl calls back into ocaml code. There is a risk
of ending up in a deadlock when a thread holds both locks at the same time,
then temporarily drop the ocaml lock, while another thread calls another libxl
function.
To avoid deadlocks, we drop the ocaml heap lock before entering libxl, and
reacquire it in callbacks to ocaml. This way, the ocaml heap lock is never held
together with the libxl lock, except in osevent registration callbacks, and
xentoollog callbacks. If we guarantee to not call any libxl functions inside
those callbacks, we can avoid deadlocks.
This patch handle the dropping and reacquiring of the ocaml heap lock by the
caml_enter_blocking_section and caml_leave_blocking_section functions, and
related macros. We are also careful to not call any functions that access the
ocaml heap while the ocaml heap lock is dropped. This often involves copying
ocaml values to C before dropping the ocaml lock.
The ao_how in aohow_val is now malloc'ed, just to make this function a little
easier to use.
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Also:
* Reorganise toplevel OCaml functions into modules of Xenlight.
* Factor out the management of ao_how into the function aohow_val. The ao_how
is now malloc'ed, just to make this function a little easier to use.
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Having bindings to the low-level functions libxl_osevent_register_hooks and
related, allows to run an event loop in OCaml; either one we write ourselves,
or one that is available elsewhere.
The Lwt cooperative threads library (http://ocsigen.org/lwt/), which is quite
popular these days, has an event loop that can be easily extended to poll any
additional fds that we get from libxl. Lwt provides a "lightweight" threading
model, which does not let you run any other (POSIX) threads in your
application, and therefore excludes an event loop implemented in the C
bindings.
Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Acked-by: David Scott <dave.scott@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This commit introduces "check-xl-vcpupin-parse" for helping
verifying and debugging the (v)CPU bitmap parsing code in xl.
The script runs "xl -N vcpu-pin 0 all <some strings>"
repeatedly, with various input strings, and checks that the
output is as expected.
This is what the script can do:
# ./check-xl-vcpupin-parse -h
usage: ./check-xl-vcpupin-parse [options]
Tests various vcpu-pinning strings. If run without arguments acts
as follows:
- generates some test data and saves them in
check-xl-vcpupin-parse.data;
- tests all the generated configurations (reading them back from
check-xl-vcpupin-parse.data).
An example of a test vector file is provided in
check-xl-vcpupin-parse.data-example.
Options:
-h prints this message
-r seed uses seed for initializing the rundom number generator
(default: the script PID)
-s string tries using string as a vcpu pinning configuration and
reports whether that succeeds or not
-o ofile save the test data in ofile
(default: check-xl-vcpupin-parse.data)
-i ifile read test data from ifile
An example test data file (generated on a 2 NUMA nodes, 16 CPUs
host) is being provided in check-xl-vcpupin-parse.data-example.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
As it can be useful to see if the outcome of some complex vCPU
pinning bitmap specification looks as expected.
This also allow for the introduction of some automatic testing
and verification for the bitmap parsing code, as it happens
already in check-xl-disk-parse and check-xl-vif-parse.
In particular, to make the above possible, this commit also
changes the implementation of the vcpu-pin command so that,
instead of always returning 0, it returns an error if the
parsing fails.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Making it possible to use something like the following:
* "nodes:0-3": all pCPUs of nodes 0,1,2,3;
* "nodes:0-3,^node:2": all pCPUS of nodes 0,1,3;
* "1,nodes:1-2,^6": pCPU 1 plus all pCPUs of nodes 1,2
but not pCPU 6;
* ...
In both domain config file and `xl vcpu-pin'.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
In libxc, make xc_get_max_{cpus,node}() always return either a
positive number or -1, and change all the callers to deal with
that.
In libxl, make libxl_get_max_{cpus,nodes}() always return either a
positive number or a libxl error code. Thanks to that, it is also
possible to fix loggig for libxl_{cpu,node}_bitmap_alloc(), which
now happens inside the functions themselves, more accurately
reporting what happened.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
in libxl_utils.c (from .h), as they will be reworked in
the next commit ("libxc/libxl: sanitize error handling in
*_get_max_{cpus,nodes}") and we want to keep code motion
separate from functional changes.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
more specifically, of the cpumap inside libxl_vcpuinfo, in case
of failure after it has been allocated.
While at it, use the correct libxl memory allocation wrapper for
calloc() in there and turn the function into using the new LOGE()
logging style.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
so that the parameter that returns the number of pCPUs is
called nr_cpus_out, while the one that returns the number of
vCPUs is called nr_vcpus_out.
The patch is all about renaming, so no functional change.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
in fact, pinning to all the pcpus happens by specifying "all"
(either on the command line or in the config file), while `xl
vcpu-list' report it as "any cpu".
Change this into something more consistent, by using "all"
everywhere.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Usage: spiceusbredirection=NUMBER (default=0)
Enables spice usbredirection. Creates NUMBER usbredirection channels
for redirection of up to 4 usb devices from spice client to domU's qemu.
It requires an usb controller and if not defined will automatically adds
an usb2 controller.
Changes from v3:
- fixed condition that enable usbversion if it isn't defined in presence
of usbredirection enabled
Changes from v2:
- updated for usbversion patch v7
- now usbredirection cannot be used with usb and usbdevice parameters
- if usbversion is undefined it will creates an usb2 controller
Changes from v1:
- Now can be setted the number of redirection channels.
- Various code improvements.
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Usage: usbversion=1|2|3 (default=0, no usb controller defined)
Specifies the type of an emulated USB bus in the guest. 1 for usb1,
2 for usb2 and 3 for usb3, it is available only with upstream qemu.
The old usb and usbdevice parameters cannot be used with this.
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
OVMF info contains E820 map allocated by hvmloader. This info is passed
to OVMF to help it do proper initialization.
Currently only E820 is necessary, but we reserve spaces for other tables
in ovmf_info for later usage.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
xc_interface_close() crashes if it gets NULL as an argument. However,
it just calls xc_interface_close_common() which is called by many
others functions. It means that they are also vulnerable. So fix above
mentioned issue by adding NULL check in xc_interface_close_common().
This way we fix similar issue in other functions which calls
xc_interface_close_common() too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Storing it in a 32-bit variable in struct arch_vcpu caused breakage over
context switch.
There were also several other places which stored this as the 32-bit value.
Update them all.
The "struct vcpu_guest_context" case needs special consideration. This struct
is in theory is exposed to guests, via the VCPUOP_initialise hypercall.
However as discussed in
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00912.html this isn't
really a guest visible interface since ARM uses PSCI for VCPU bringup
(VCPUOP_initialise simply isn't available) The other users of this interface
are the domctls, which are not a stable API. Therefore while fixing the ttbcr
size also surround the struct in ifdefs to restrict the struct to the
hypervisor and the tools only (omitting the extra complexity of renaming as I
suggested in the referenced thread).
NB TCR_EL1 on arm64 is known as TTBCR on arm32, hence the apparent naming
inconsistencies.
Spotted-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Cc: Anup Patel <anup.patel@linaro.org>
Cc: patches@linaro.org
Cc: patches@apm.com
Do this by changing the function to not use stdio file operations, but
just use the fd directly with libxl_write_exactly.
While at it, tidy up the function's style issues.
Coverity-ID: 1056195
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Use libxl__zallocs instead of plain mallocs + memset.
Coverity-ID: 1055889
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
If initializing the ctx's lock fails, don't keep going, but instead
error out.
Coverity-ID: 1055289
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
...from libxl_cpuid_parse_config_xend. value is unsigned so this doesn't
work, and either way the following comparison on it being bigger than 3
does what was intended here anyway.
Coverity-ID: 1055614
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
It could, even if only in theory, be fd 0.
(This is not the same as commit 4b62556b57!)
Coverity-ID: 1055895
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The ptr calculation shall take the offset into the page into account
when ptr is valid.
Reported regression on NetBSD's port-xen with last known working libxen
being rev 2.9. This corrupts the kernel symbol table when the table is
not loaded on a page boundary.
Issue was tracked down by FastIce and Jeff Rizzo. See also
http://mail-index.netbsd.org/port-xen/2013/10/16/msg008088.html
Signed-off-by: Jean-Yves Migeon <jym@NetBSD.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Load OVMF from (100000000ULL - sizeof(ovmf)) to 0xFFFFFFFF, with proper
rounding down.
Tested with OVMF release build (1 MB) and debug build (2 MB), both
worked fine.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Campbell
Matthew Daley
Andrew Cooper
Rob Hoes
Dario Faggioli
Fabio Fantoni
Wei Liu
Daniel Kiper
Nathan Studer
Jean-Yves Migeon