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>
Currently an unhandled data abort in guest context leads to us killing the
guest and an unhandled instruction abort in guest context leads to us killing
the host!
Andre pointed out that an unhandled data abort can be caused by e.g. dmidecode
looking for things which are not there in the guests physical address space.
Propagating the fault to the guest allows it to properly SIGSEGV the
processes.
A guest kernel can trivially jump to an unmapped physical address which would
cause an instruction abort. Killing the host for that is obviously bad.
Instead inject the exception so the guest kernel can SIGSEGV or panic() etc as
it deems appropriate.
Tested on arm64 (Mustang) and arm32 (Midway) with a dom0 kernel late_initcall
which either dereferences or jumps to address 0, provoking both behaviours and
resulting correctly in a guest kernel panic. Also tested on fast models with a
32-bit dom0 on a 64-bit hypervisor, which behaved correctly.
In addition tested on both platforms with a userspace program which either
calls to or dereferences address 0. The process is correctly killed with SEGV.
Lastly tested on Mustang with a 32-bit version of the userspace test on a
64-bit dom0 kernel.
I think that covers all the cases.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Andre Przywara <andre.przywara@calxeda.com>
[ ijc -- fixed up whitespace in if statements in cpsr_mode_switch ]
The commit d963923 "xen: arm: correct return value of
raw_copy_{to/from}_guest_*, raw_clear_guest" doesn't permit to boot guest
on Xen ARM.
Remove the stray semicolon from the end of the if statement.
Also we want to get the right rc in the error arrays, so we need to do the
copy_to_guest_offset before checking the rc returned by
xenmem_add_to_physmap_one.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- expanded commit log ]
This is a generic interface which is supposed to return the number of bytes
which were not copied. Make it so.
Update the incorrect callers prepare_dtb, decode_thumb{2} and
xenmem_add_to_physmap_range.
In the xenmem_add_to_physmap_range case, observe that we are not propagating
errors from xenmem_add_to_physmap_one and do so.
In the decode_thumb case and an emacs magic block to decode.c
Make the flush_dcache parameter to the helper an int while at it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
We don't actually use this but I was using it locally for debugging and it
tripped me up.
Also add DCCIMVAC "data cache clean and invalidate by MVA" which is the only
cache op missing from cpregs.h.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
The Xgene platform has no RAM below 4G.
The /chosen/linux,initrd-* properties do not have "reg" semantics and
therefore #*-size are not used when interpreting. Instead they are are simply
numbers which are interpreted according to the properties length.
Fix this both when parsing the entry in the host DTB and when creating the
dom0 DTB. For dom0 we simply hardcode a 64-bit size, this is acceptable
even for a 32-bit guest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
The BUG_ON in p2m_map_first was over aggressive since the paddr_t can have
come from the guest, via add_to_physmap. Instead return failure to the caller.
Also the check was simultaneously too lose. The valid offsets are
0..P2M_FIRST_ENTRIES-1 inclusive.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
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>
This avoids a resource leak and needless playing with the pagetables in the
case that the page is broken.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
Reviewed-by: Keir Fraser <keir@xen.org>
The previous call before alloc_xenheap_pages reset rc to 0 if it success.
If the latter fails, arch_domain_create will return 0 and Xen will consider
the domain as valid. Move rc initialization later.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
__map_domain_page() *must* be matched with an unmap_domain_page(). These five
static inline functions each map a page (or two), then throw away the context
needed to unmap it.
Each of the changes are limited to their respective functions. In two cases,
this involved replacing a large amount of pointer arithmetic with memcpy()
(all callers were relying on memcpy() semantics of positive/negative returns
rather than specifically -1/+1). A third case had its pointer arithmetic
entirely replaced with memcpy().
In addition, remove redundant casts of void pointers and assertions.
This fixes Coverity IDs 1135373 1135374 1135375 1135376 1135377 1135378
11353739 which were retroactively identified following modelling improvements.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: Bob Liu <bob.liu@oracle.com>
Commit 006a687ba4 dropped typedef tmem_cli_mfn_t
from public tmem.h which may cause some problem.
This patch added tmem_cli_mfn_t back with #ifdef __XEN_INTERFACE_VERSION__
around.
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.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>
arm32 currently only makes use of memory which is contiguous with the first
bank. On the Midway platform this means that we only use 4GB of the 8GB
available.
Change things to make use of non-contiguous memory regions with the
restriction that we require that at least half of the total span of the RAM
addresses contain RAM. The frametable is currently not sparse and so this
restriction avoids problems with allocating enormous amounts of memory for the
frametable to cover holes in the address space and exhausting the actual RAM.
50% is arguably too restrictive. 4GB of RAM requires 32MB of frametable on
arm32 and 56M on arm64, so we could probably cope with a lower ratio of actual
RAM. However half is nice and conservative.
arm64 currently uses all banks without regard for the size of the frametable,
which I have observed causing problems on models. Implement that same
restriction as arm32 there.
Long term we should look at moving to a pfn compression based scheme similar
to x86, which removes the holes from the frametable.
There were some bogus/outdated comments scattered around this code which I
have removed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>
The DT provided to guests (including dom0) includes a Xen node which, among
other things, describes an MMIO region which can be safely used for grant
table mappings (i.e. it is a hole in the physical address space). For domU we
provide a hardcoded values based on our hardcoded guest virtual machine
layout. However for dom0 we need to fit in with the underlying platform.
Leaving this hardcoded was an oversight which on some platforms could result
in the grant table overlaying RAM or MMIO regions which are in use by domain
0.
For the 4.4 release do as we did with the dom0 evtchn PPI and provide a hook
for the platform code to supply a suitable hardcoded address for the platform
(derived from reading the data sheet). Platforms which do not provide the hook
get the existing address as a default.
After 4.4 we should switch to selecting a region of host RAM which is not RAM
in the guest address map. This should be more flexible and safer but the patch
was looking too complex for 4.4.
Platform Gnttab Address
======== ==============
exynos5.c 0xb0000000, confirmed and tested by Julien.
sunxi.c 0x01d00000, confirmed in data sheet.
midway.c 0xff800000, confirmed by Andre, boot tested by Ian.
vexpress.c 0xb0000000, existing hardcoded value was selected for vexpress.
omap5.c 0x4b000000, confirmed by Baozi
xgene-storm.c 0x1f800000, confirmed by Pranavkumar
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Julien.Grall@linaro.org
Cc: Stefano.Stabellini@eu.citrix.com
Cc: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Chen Baozi <baozich@gmail.com>
Acked-by: Pranavkumar Sawargaonkar <psawargaonkar@apm.com>
Cc: Anup Patel <apatel@apm.com>
IBM System x3530 M4 BIOSes (including the latest available at the time of this
patch) will corrupt a byte at physical address 0x105ff1 to the value of 0x86
if %esp has the value 0x00080000 when issuing an `int $0x15 (ax=0xec00)` to
inform the system about our intended operating mode.
Xen gets unhappy when the bootloader has placed it's .text section in over
this specific region of RAM.
After dropping into 16bit mode, clear all 32 bits of %esp, and for the BIOS
call already documented to be affected by BIOS bugs clear all GPRs.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This reverts commit 86d60e85 as well as one related change from
62652c00 ("VMX: fix cr0.cd handling"), on the basis that all of this
flushing is still insufficient and, while not known to fix anything, is
known to negatively affect performance.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Release-acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Liu Jinsong <jinsong.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch fixs two issues:
1. The CR_READ_SHADOW should only cover the value that L2 wirtes to
CR when L2 is running. But currently, L0 wirtes wrong value to
it during virtual vmentry and L2's CR access emualtion.
2. L2 changed cr[0/4] in a way that did not change any of L1's shadowed
bits, but did change L0 shadowed bits. In this case, the effective cr[0/4]
value that L1 would like to write into the hardware is consist of
the L2-owned bits from the new value combined with the L1-owned bits
from L1's guest cr[0/4].
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
If the device tree contains a PSCI node and the DTB CPU node tells us
to use PSCI for enabling secondary cores, we set the function pointer
to the PSCI wrapper function to enable PSCI SMP bringup.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
If the device tree contains a PSCI node, we bring up secondary CPUs
by invoking the appropriate PSCI handler.
This will take priority over platform specific functions (which could
call the PSCI wrapper themselves if needed), so any PSCI enablement
of a platform will automatically be used (as on Linux).
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The PSCI handler is invoked via a secure monitor call with the
arguments defined in registers. Copy the function from the
Linux code and adjust it to work on both ARM32 and ARM64.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The availability of a PSCI handler is advertised in the DTB.
Find and parse the node (described in the Linux device-tree binding)
and save the function number for bringing up a CPU for later usage.
We do some sanity checks, especially we deny using HVC as a calling
method, as it does not make much sense currently under Xen.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently we unconditionally send SGIs to all cores on SMP bringup.
Those SGIs (software generated interrupts) are to push a secondary core
through a gate in the Xen bring up code to filter the right CPU. This gate is
necessary on platforms which do not allow us to wake up a specific secondary
processor and will trap all but the CPU we are trying to wake up.
With PSCI we can explicitly specify the core to startup, so we don't need the
kick here because the CPU will fall straight through Xen's gate.
So we move the GIC kick into a function and call it explicitly from the
platforms that need it. This gets us get rid of the empty cpu_up() platform
functions in ARM32 and the comment in there.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- explain more about the Xen gate in the commit message ]
Follow the current convention of prefixing guest related names
with "v" by renaming the guest PSCI functionality into vpsci.c to make
room for the host PSCI functions.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
I was just about to send out patches adding the 1:1 workaround to vexpress
(the foundation model is a vexpress platfrom with DMA) and sunxi.
That would have meant that all platforms now implement the quirk. Instead lets
just make it the default and remove the quirk.
In the future this will likely be set based on the presence absence of an
IOMMU, perhaps with additional overrides by the platform.
This results in some dead code in domain_build for dealing with the non-1:1
case. This is deliberate and is left in anticipation of IOMMU support in 4.5.
PLATFORM_QUIRK_GIC_64K_STRIDE is renumbered as a side effect of this change.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Rob Hoes
Ian Campbell
Julien Grall
Wei Liu
Dario Faggioli
Andrew Cooper
Bob Liu
Fabio Fantoni
Jan Beulich
Yang Zhang
Andre Przywara
Ian Jackson
Dennis Lan (dlan)
Anthony PERARD