There is no conceptual problem with setting this parameter more than once.
Checkpointed migration streams will typically set it once per checkpoint to
the same value.
The parameter is only actually needed on early-generation VT-x which lacked
the unrestricted guest capability, although it could plausibly be used on
newer VT-x with unusual execution control settings. Short circuit the
expensive operations on non VT-x hardware.
The parameter itself must always be latched to avoid issues if the VM
eventually migrates to a host which needs to use the pagetable.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
My recent patch "use white-lists for HVM param guest accessibility checks"
(commit 30efda12d6) introduced a regression
when saving and restoring Windows guests running Xen Project PV drivers.
The drivers reset the event channel ABI on resume. This has the effect of
closing the store and console local event channel ports created by the
toolstack. The drivers do not currently use the console port but they
do use the store port and thus, prior to reset, they sample the remote
domain and port and then re-bind the channel - yielding a new and possibly
different local port - after reset. They then store the new local port
value in HVM_PARAM_CONSOLE_EVTCHN. That operation now fails and may
lead to a crash, if using a debug build of the drivers, or a barely
functional connection to xentored if not.
This patch adds HVM_PARAM_STORE_EVTCHN and HVM_PARAM_CONSOLE_EVTCHN to
the guest-settable white-list since either of them can be invalidated
by an event channel ABI reset and thus the guest may indeed need to
write new values to them to make them valid again.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
On arm64, either firmware or xen's smp_up_cpu gate uses WFE on secondary
cpus to stand-by when booting. Thus, using SEV is enough for the boot
cpu to kick other secondaries. Further more, the current implementation
of cpu_up_send_sgi would pass a NULL cpumask pointer to send_SGI, which
then lead a data fault on GICv3 send_SGI implementation.
Signed-off-by: Chen Baozi <baozich@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Since fdt_begin_node() is called by all gicXX_make_dt_node() to create
the interrupt-controller devicetree node, this patch refactors the call
and moves it inside make_gic_node(). This also matches the fdt_end_node()
call at the end of make_gic_node().
This patch also move the call to gic_make_node() wrapper to be after all
other generic properties are setup. This allows creating sub-node inside
gic_make_node() in order to support v2m sub-node.
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Although in principal #interrupt-cells can vary it must always be 3
for a GIC (and we only support GIC as a guest interrupt controller),
so putting it in common code is OK.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
ARM and x86 use a different hypercall to map an IRQ to a domain.
The hypercall to give IRQ permission to the domain has also been moved
to be an x86 specific function as ARM guest won't be able to manage the IRQ.
We may want to support it later.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
A device node is described by a path. It will be used to retrieve the
node in the device tree and assign the related device to the domain.
Only non-PCI devices protected by an IOMMU can be assigned to a guest.
Also document the behavior of XEN_DOMCTL_deassign_device in the public
headers which differ between non-PCI and PCI.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
This is a follow-up of commit 525ee49 "xsm: add device tree labeling
support" which add support for device tree labelling in flask.
Those helpers will be use latter when non-pci passthrough (i.e device
tree) will be added.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Currently, when the device is deassigned from a domain, we directly reassign
to DOM0.
As the device may not have been correctly reset, this may lead to corruption or
expose some part of DOM0 memory. Also, we may have no way to reset some
platform devices.
If Xen reassigns the device to "nobody", it may receive some global/context
fault because the transaction has failed (indeed the context has been
marked invalid). Unfortunately there is no simple way to quiesce a buggy
hardware. I think we could live with that for a first version of platform
device passthrough.
DOM0 will have to issue an hypercall to assign the device to itself if it
wants to use it.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The toolstack may not have deassigned every device used by a guest.
Therefore we have to go through the device list and remove them before
asking the IOMMU drivers to release memory for this domain.
This can be done by moving the call to the release function when we
relinquish the resources. The IOMMU part will be destroyed later when
the domain is freed.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Robert VanVossen <robert.vanvossen@dornerworks.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This new function will correctly initialize the IOMMU page table for the
current domain.
Also use it in iommu_assign_dt_device even though the current IOMMU
implementation on ARM shares P2M with the processor.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The maximum size of the copied string has been chosen based on the value
use by XSM in similar case.
Furthermore, Linux seems to allow path up to 4096 characters. Though
this could vary from one OS to another.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Flask code already provides a helper to copy a string from guest. In a later
patch, the new DT hypercalls will need a similar function.
To avoid code duplication, copy the flask helper (flask_copying_string) to
common code:
- Rename into safe_copy_string_from_guest
- Add comment to explain the extra +1
- Return the buffer directly and use the macros provided by
xen/err.h to return an error code if necessary.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
On x86, an IRQ is assigned in 2 steps to an HVM guest:
- The toolstack is calling PHYSDEVOP_map_pirq in order to create a
guest PIRQ (IRQ bound to an event channel)
- The emulator (QEMU) is calling DOMCTL_bind_pt_irq in order to
bind the IRQ
On ARM, there is no concept of PIRQ as the IRQ can be assigned to a
virtual IRQ using the interrupt controller.
It's not clear if we will need 2 different hypercalls on ARM to assign
IRQ and, for now, only the toolstack will manage IRQ.
In order to avoid re-using a fixed ABI hypercall (PHYSDEVOP_*) for a
different purpose and allow us more time to figure out the right out,
only DOMCTL_{,un}bind_pt_pirq is implemented on ARM.
The DOMCTL is extended with a new type PT_IRQ_TYPE_SPI and only IRQ ==
vIRQ (i.e machine_irq == spi) is supported.
In order to keep the same XSM checks done by the 2 hypercalls on x86,
call both xsm_map_domain_irq & xsm_bind_pt_irq in the ARM implementation.
Note: The toolstack changes for routing an IRQ to a guest will be done
in a separate patch.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Jan Beulich <jbeulich@suse.com>
Xen has to release IRQ routed to a domain in order to reuse later.
Currently only SPIs can be routed to the guest so we only need to
browse SPIs for a specific domain.
Furthermore, a guest can crash and leave the IRQ in an incorrect state
(i.e has not been EOIed). Xen will have to reset the IRQ in order to
be able to reuse the IRQ later.
Introduce 2 new functions for release an IRQ routed to a domain:
- release_guest_irq: upper level to retrieve the IRQ, call the GIC
code and release the action
- gic_remove_guest_irq: Check if we can remove the IRQ, and reset
it if necessary
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Introduce spi_to_pending in order retrieve the irq_pending structure for
a specific SPI.
It's not possible to re-use irq_to_pending because it's required a VCPU
and some call of the new function may during domain destruction after
the VCPUs are freed.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Each domain may have a different number of IRQs depending on the devices
assigned to it.
Rather than re-using the number of IRQs used by the hardwared GIC, let
the toolstack specify the number of SPIs when the domain is created.
This will avoid wasting memory.
To calculate the number of SPIs, we take advantage of the fact that the
libxl interface can only expose 1:1 mapping and look for the largest SPI
in the list.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Handle NULL pointer passed to xlu_cfg_destroy. libvirt calls it in its
libxlDriverConfigDispose function. If the XLU_Config was not initialized
yet for some reason a crash would occur on cleanup.
Avoid the crash just like libxl_ctx_free and xtl_logger_destroy do when
called from the same context.
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>
Usage:
vga="qxl"
Qxl vga support many resolutions that not supported by stdvga,
mainly the 16:9 ones and other high up to 2560x1600.
With QXL you can get improved performance and smooth video also
with high resolutions and high quality.
Require their drivers installed in the domU and spice used
otherwise act as a simple stdvga.
Signed-off-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Signed-off-by: Zhou Peng <zpengxen@gmail.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
xentrace is the only caller at the moment. Split the cpu and event
mask setting out into seperate functions, but leave the current limit
of 32 bits for masks passed in from the command-line.
Based on a patch from Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
We export the xc_cpumap_alloc but not the bit operations.
One could include 'xc_bitops.h' but that is naughty - so instead
we just export the proper functions to do it on the xc_cpumap_t
typedef.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
----
v2: Use our own macro to make sure ARM is not affected negatively
v3: Lifted Ian's explanation.
I was unable to find an ARMv8 ARM reference to this, so refer to the
GIC Architecture Specification instead.
ARMv8 ARM does cover other ways of trapping these accesses via
ICH_HCR_EL2 but we don't use those and they trap additional registers
as well.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
We set CNTHCTL_EL2.EL1PCTEN and therefore according to ARMv8 (DDI
0487A.d) D1-1510 Table D1-60 we are not trapping this.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Gather the affected handlers in a single place per trap type.
Add some HSR_SYSREG and AArch32 defines for those registers (because
I'd already typed them in when I realised I didn't need them).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
DBGDRAR and DBGDSAR are actually two cp or sys registers each, one
32-bit and one 64-bit. The cpregs #define is suffixed "64" and
annotations are added to both handlers.
MDRAR_EL1 (arm64 version of DBGDRAR) wasn't handled, so add that here.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Also expand on the comment when writing CPTR_EL2 to mention that most
of the bits we are setting are RES1 on arm64 anyway.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Add explicit handler for 64-bit CP14 accesses, with more relevant
debug message (as per other handlers) and to provide a place for a
comment.
The docs just say "All implemented trace registers." so reflect that
in the comment since there is no explicit list.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
This traps variety of implementation defined registers, so add a note
to the default case of the respective handler.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
While annotating ACTLR I noticed that we don't appear to handle the
64-bit version of this trap. Do so and annotate everything.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reference the bit which enables the trap and the section/page which
describes what that bit enables.
These ones are pretty trivial, included for completeness.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Reduces the use of goto in the trap handlers to none.
Some explicitly 32-bit types become register_t here, but that's OK, on
32-bit they are 32-bit already and on 64-bit it is fine/harmless to
set the larger register, a 32-bit guest won't see the top half in any
case.
Per section B1.2.1 (ARMv8 DDI0487 A.d) writes to wN registers are zero
extended, so there is no risk of leaking the top half here.
Unlike the previous code the advancing of PC is handled within the
helper, rather than after the end of the switch as before. So return
as the handler is called.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Having injected an undefined instruction we don't want to also advance
pc. So return.
The ICC_{SGI0R,ASGI1R}_EL1 case was previously missing a break, so
would have fallen through to the default case and injected a second
undef, corrupting SPSR_EL1 and ELR_EL1 for the guest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
Pack struct paging_domain to reduce it by 8 bytes. Thus reducing the
size of struct domain by 8 bytes.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Andrew Cooper
Wei Liu
Julien Grall
Paul Durrant
Jan Beulich
Chen Baozi
Suravee Suthikulpanit
Ian Campbell
Julien Grall
Olaf Hering
Fabio Fantoni
George Dunlap
Konrad Rzeszutek Wilk
David Vrabel