Andrew Cooper [Fri, 9 Mar 2018 13:03:26 +0000 (13:03 +0000)]
tools/libxl: Don't prepare or save xc_config when soft resetting a domain
xc_config is only used by xc_domain_create(), but by calling
libxl__arch_domain_{prepare,save}_config() we clobber the real settings with
the default settings.
Move all data and calls relating to xc_domain_create() into the path which
calls it.
As far as I can tell, soft_reset has always been broken for ARM domains using
LIBXL_GIC_VERSION_DEFAULT, which elicits a hard error out of
libxl__arch_domain_save_config(), and only works on x86 because this function
is a no-op.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Andrew Cooper [Fri, 9 Mar 2018 12:24:13 +0000 (12:24 +0000)]
tools/libxl: Drop xc_domain_configuration_t from libxl__domain_build_state
The data it stores is initialised and exclusively used within
libxl__domain_make(), with the important details written back elsewhere by
libxl__arch_domain_save_config(). Prepare xc_config on libxl__domain_make()'s
stack, and drop the parameter.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Sergey Dyasli [Thu, 22 Mar 2018 11:32:36 +0000 (11:32 +0000)]
x86/cpuid: update signature of hvm_cr4_guest_valid_bits()
With the new cpuid infrastructure there is a domain-wide struct cpuid
policy and there is no need to pass a separate struct vcpu * into
hvm_cr4_guest_valid_bits() anymore. Make the function accept struct
domain * instead and update callers.
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Razvan Cojocaru [Fri, 30 Mar 2018 15:39:05 +0000 (18:39 +0300)]
x86/altp2m: support for setting restrictions for an array of pages
For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addresses the gap.
HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to a
DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart (and
hence with the original altp2m design, where domains are allowed - with the
proper altp2m access rights - to alter these settings), in the absence of an
official position on the issue from the original altp2m designers.
Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> Signed-off-by: Petre Pircalabu <ppircalabu@bitdefender.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
Wei Liu [Wed, 4 Apr 2018 11:03:14 +0000 (12:03 +0100)]
x86/hvm/ioreq: fix two bugs in hvm_create_ioreq_server
It is possible to call the error path with i pointing beyond the end
of the array.
There is another bug that if there is already a default ioreq server,
the code will actually sets the element to NULL, hence leaking memory.
Move setting NULL to where it is needed.
Coverity-ID: 1433777 Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Paul Durrant [Mon, 31 Jul 2017 15:28:39 +0000 (16:28 +0100)]
tools/libxenforeignmemory: add support for resource mapping
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
Paul Durrant [Mon, 30 Oct 2017 11:39:33 +0000 (11:39 +0000)]
x86/mm: add an extra command to HYPERVISOR_mmu_update...
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_translate set in its paging mode and, if it does, assumes that the
the pfn value in the l1e is a gfn rather than an mfn.
To allow PV tools domain to map mfn values from a previously issued
HYPERVISOR_memory_op:XENMEM_acquire_resource, there needs to be a way
to tell HYPERVISOR_mmu_update that the specific l1e value does not
require translation regardless of the paging mode of foreign_dom. This
patch therefore defines a new command value, MMU_PT_UPDATE_NO_TRANSLATE,
which has the same semantics as MMU_NORMAL_PT_UPDATE except that the
paging mode of foreign_dom is ignored and the l1e value is used verbatim.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant [Wed, 9 Aug 2017 16:39:01 +0000 (17:39 +0100)]
x86/hvm/ioreq: add a new mappable resource type...
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages which are assigned to the
emulating domain. These pages will never be present in the P2M of the
guest at any point (and are not even shared with the guest) and so are not
vulnerable to any direct attack by the guest.
NOTE: Use of the new resource type is not compatible with use of
XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
set.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <julien.grall@arm.com>
Paul Durrant [Wed, 27 Sep 2017 09:00:54 +0000 (10:00 +0100)]
x86/mm: add HYPERVISOR_memory_op to acquire guest resources
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsically specific to the x86 architecture,
I have no means to test it on an ARM platform and so cannot verify
that it functions correctly.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <julien.grall@arm.com>
Paul Durrant [Wed, 9 Aug 2017 15:22:35 +0000 (16:22 +0100)]
x86/hvm/ioreq: defer mapping gfns until they are actually requested
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant [Wed, 9 Aug 2017 13:19:25 +0000 (14:19 +0100)]
x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant [Thu, 3 Aug 2017 14:35:26 +0000 (15:35 +0100)]
x86/hvm/ioreq: simplify code and use consistent naming
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
to determine whether they need to act. This means can be safely called
for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
to mirror the existing hvm_ioreq_server_unmap_pages().
All of this significantly shortens the code.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Paul Durrant [Wed, 21 Mar 2018 14:00:37 +0000 (14:00 +0000)]
x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies the code to maintain an array of
that size rather than using a list.
Also, by reserving an array slot for the default server and populating
array slots early in create, the need to pass an 'is_default' boolean
to sub-functions can be avoided.
Some function return values are changed by this patch: Specifically, in
the case where the id of the default ioreq server is passed in, -EOPNOTSUPP
is now returned rather than -ENOENT.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Boris Ostrovsky [Tue, 3 Apr 2018 06:05:21 +0000 (23:05 -0700)]
libxc: Pass e820 map to HVM/PVH guests via hvm_start_info
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Maran Wilson <maran.wilson@oracle.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Tue, 3 Apr 2018 06:05:20 +0000 (23:05 -0700)]
libxl: Store e820 map in xc_dom_image
We will later copy it to hvm_start_info.
(Also remove stale comment claming that xc_dom_image.start_info_seg is
only used for HVMlite guests)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Boris Ostrovsky [Tue, 3 Apr 2018 06:05:19 +0000 (23:05 -0700)]
libxl/x86: Build e820 map earlier for HVM/PVH guests
Since hvm_start_info has now been expanded to include memory map (i.e.
e820) we need to know size of this map by the time we create
dom->start_info_seg in alloc_magic_pages_hvm().
To do so we have to call libxl__arch_domain_construct_memmap() earlier,
before xc_dom_build_image(). And since libxl__arch_domain_construct_memmap()
is only used by for x86 we can make this call from x86's
libxl__arch_domain_finalise_hw_description(), at the same time removing
its NOP definition from ARM code and renaming and making it static in
libxl_x86.c
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Maran Wilson [Tue, 3 Apr 2018 06:05:18 +0000 (23:05 -0700)]
x86/PVHv2: Add memory map pointer to hvm_start_info struct
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by: Maran Wilson <maran.wilson@oracle.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Andre Przywara [Thu, 24 Aug 2017 16:26:32 +0000 (17:26 +0100)]
ARM: VGIC: wire new VGIC(-v2) files into Xen build system
Now that we have both the old VGIC prepared to cope with a sibling and
the code for the new VGIC in place, lets add a Kconfig option to enable
the new code and wire it into the Xen build system.
This will add a compile time option to use either the "old" or the "new"
VGIC.
In the moment this is restricted to a vGIC-v2. To make the build system
happy, we provide a temporary dummy implementation of
vgic_v3_setup_hw() to allow building for now.
Andre Przywara [Thu, 21 Dec 2017 12:41:28 +0000 (12:41 +0000)]
ARM: new VGIC: Allocate two pages for struct vcpu
At the moment we allocate exactly one page for struct vcpu on ARM, also
have a check in place to prevent it growing beyond 4KB.
As the struct includes the state of all 32 private (per-VCPU) interrupts,
we are at 3840 bytes on arm64 at the moment already. Growing the per-IRQ
VGIC structure even slightly makes the VCPU quickly exceed the 4K limit.
The new VGIC will need more space per virtual IRQ. I spent a few hours
trying to trim this down, but couldn't get it below 4KB, even with the
nasty hacks piling up to save some bytes here and there.
It turns out that beyond efficiency, maybe, there is no real technical
reason this struct has to fit in one page, so lifting the limit to two
pages seems like the most pragmatic solution.
Restrict the compilation error to compiling with the new VGIC and for
ARM64 only.
Andre Przywara [Wed, 7 Feb 2018 14:54:23 +0000 (14:54 +0000)]
ARM: new VGIC: vgic-init: implement map_resources
map_resources is the last initialization step needed before the first
VCPU is run. At that stage the code stores the MMIO base addresses used.
Also it registers the respective register frames with the MMIO framework.
This is based on Linux commit cbae53e663ea, written by Eric Auger.
Andre Przywara [Thu, 8 Feb 2018 18:40:45 +0000 (18:40 +0000)]
ARM: new VGIC: vgic-init: implement vgic_init
This patch allocates and initializes the data structures used to model
the vgic distributor and virtual cpu interfaces. At that stage the
number of IRQs and number of virtual CPUs is frozen.
Implement the various functions that the Xen arch code is expecting to
call during domain and VCPU setup to initialize the VGIC.
Their prototypes are already in existing header files.
This is based on Linux commit ad275b8bb1e6, written by Eric Auger.
Andre Przywara [Thu, 8 Feb 2018 18:44:38 +0000 (18:44 +0000)]
ARM: new VGIC: vgic-init: register VGIC
This patch implements the function which is called by Xen when it wants
to register the virtual GIC.
This also implements vgic_max_vcpus() for the new VGIC, which reports
back the maximum number of VCPUs a certain GIC model supports. Similar
to the counterpart in the "old" VGIC, we return some maximum value if
the VGIC has not been initialised yet.
Andre Przywara [Wed, 7 Feb 2018 13:58:19 +0000 (13:58 +0000)]
ARM: new VGIC: Add preliminary stub implementation
The ARM arch code requires an interrupt controller emulation to implement
vgic_clear_pending_irqs(), although it is suspected that it is actually
not necessary. Go with a stub for now to make the linker happy.
Andre Przywara [Mon, 5 Mar 2018 11:13:36 +0000 (11:13 +0000)]
ARM: new VGIC: Implement arch_move_irqs()
When a VCPU moves to another CPU, we need to adjust the target affinity
of any hardware mapped vIRQs, to observe our "physical-follows-virtual"
policy.
Implement arch_move_irqs() to adjust the physical affinity of all hardware
mapped vIRQs targetting this VCPU.
Andrew Cooper [Thu, 22 Mar 2018 17:17:20 +0000 (17:17 +0000)]
x86/pv: Fix the handing of writes to %dr7
c/s 65e35549 "x86/PV: support data breakpoint extension registers"
accidentally broke the handing of writes. The call to activate_debugregs()
doesn't write %dr7 as v->arch.debugreg[7] hasn't been updated yet, and the
break skips the intended write to %dr7.
Remove the break, causing execution to hit the write_debugreg(7, value); in
context at the bottom of the hunk, which in turn causes hardware to be updated
appropriately.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andre Przywara [Wed, 7 Feb 2018 13:59:07 +0000 (13:59 +0000)]
ARM: new VGIC: Provide system register emulation stub
The Xen arch code traps system registers writes from the guest and will
relay anything GIC related to the VGIC.
Since this affects only GICv3 (which we don't yet emulate), provide a
stub implementation of vgic_emulate() for now.
Andre Przywara [Thu, 8 Feb 2018 12:24:21 +0000 (12:24 +0000)]
ARM: new VGIC: Dump virtual IRQ info
When we dump guest state on the Xen console, we also print the state of
IRQs that are on a VCPU.
Add the code to dump the state of an IRQ handled by the new VGIC.
Andre Przywara [Wed, 7 Feb 2018 13:57:39 +0000 (13:57 +0000)]
ARM: new VGIC: Handle virtual IRQ allocation/reservation
To find an unused virtual IRQ number Xen uses a scheme to track used
virtual IRQs.
Implement this interface in the new VGIC to make the Xen core/arch code
happy.
This is actually somewhat VGIC agnostic, so is mostly a copy of the code
from the old VGIC. But it has to live in the VGIC files, so we can't
easily reuse the existing implementation.
Andre Przywara [Wed, 7 Feb 2018 13:56:57 +0000 (13:56 +0000)]
ARM: new VGIC: Add event channel IRQ handling
The Xen core/arch code relies on two abstracted functions to inject an
event channel IRQ and to query its pending state.
Implement those to query the state of the new VGIC implementation.
Andre Przywara [Wed, 7 Feb 2018 17:08:23 +0000 (17:08 +0000)]
ARM: new VGIC: Handle hardware mapped IRQs
The VGIC supports virtual IRQs to be connected to a hardware IRQ, so
when a guest EOIs the virtual interrupt, it affects the state of that
corresponding interrupt on the hardware side at the same time.
Implement the interface that the Xen arch/core code expects to connect
the virtual and the physical world.
Andre Przywara [Wed, 7 Feb 2018 17:03:50 +0000 (17:03 +0000)]
ARM: new VGIC: Add TARGET registers handlers
The target register handlers are v2 emulation specific, so their
implementation lives entirely in vgic-mmio-v2.c.
We copy the old VGIC behaviour of assigning an IRQ to the first VCPU
set in the target mask instead of making it possibly pending on
multiple VCPUs.
We update the physical affinity of a hardware mapped vIRQ on the way.
This is based on Linux commit 2c234d6f1826, written by Andre Przywara.
Andre Przywara [Wed, 7 Feb 2018 15:53:39 +0000 (15:53 +0000)]
ARM: new VGIC: Add CONFIG registers handlers
The config register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
This is based on Linux commit 79717e4ac09c, written by Andre Przywara.
Andre Przywara [Wed, 7 Feb 2018 15:53:20 +0000 (15:53 +0000)]
ARM: new VGIC: Add PRIORITY registers handlers
The priority register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
This is based on Linux commit 055658bf48fc, written by Andre Przywara.
Andre Przywara [Wed, 7 Feb 2018 15:52:48 +0000 (15:52 +0000)]
ARM: new VGIC: Add ACTIVE registers handlers
The active register handlers are shared between the v2 and v3 emulation,
so their implementation goes into vgic-mmio.c, to be easily referenced
from the v3 emulation as well later.
Since activation/deactivation of an interrupt may happen entirely in the
guest without it ever exiting, we need some extra logic to properly track
the active state.
For clearing the active state, we would basically have to halt the guest
to make sure this is properly propagated into the respective VCPUs.
This is not yet implemented in Xen.
Fortunately this feature is mostly used to reset a just in initialised
GIC, so chances are we are tasked to clear bits that are already zero.
Add a simple check to avoid pointless warnings in this case.
Andre Przywara [Wed, 7 Feb 2018 15:52:07 +0000 (15:52 +0000)]
ARM: new VGIC: Add PENDING registers handlers
The pending register handlers are shared between the v2 and v3
emulation, so their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
For level triggered interrupts the real line level is unaffected by
this write, so we keep this state separate and combine it with the
device's level to get the actual pending state.
Hardware mapped IRQs need some special handling, as their hardware state
has to be coordinated with the virtual pending bit to avoid hanging
or masked interrupts.
This is based on Linux commit 96b298000db4, written by Andre Przywara.
Andre Przywara [Wed, 7 Feb 2018 15:51:12 +0000 (15:51 +0000)]
ARM: new VGIC: Add ENABLE registers handlers
As the enable register handlers are shared between the v2 and v3
emulation, their implementation goes into vgic-mmio.c, to be easily
referenced from the v3 emulation as well later.
This introduces a vgic_sync_hardware_irq() function, which updates the
physical side of a hardware mapped virtual IRQ.
Because the existing locking order between vgic_irq->irq_lock and
irq_desc->lock dictates so, we drop the irq_lock and retake them in the
proper order.
Andre Przywara [Thu, 8 Feb 2018 11:34:40 +0000 (11:34 +0000)]
ARM: new VGIC: Add CTLR, TYPER and IIDR handlers
Those three registers are v2 emulation specific, so their implementation
lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
as their implementation is pretty simple.
We choose to piggy-back on the existing KVM identification registers,
but use a different variant (major revision).
When the guest enables the distributor, we kick all VCPUs to get
potentially pending interrupts serviced.
This is based on Linux commit 2b0cda878965, written by Marc Zyngier.
Andre Przywara [Wed, 7 Feb 2018 11:43:07 +0000 (11:43 +0000)]
ARM: new VGIC: Add GICv2 MMIO handling framework
Create vgic-mmio-v2.c to describe GICv2 emulation specific handlers
using the initializer macros provided by the VGIC MMIO framework.
Provide a function to register the GICv2 distributor registers to
the Xen MMIO framework.
The actual handler functions are still stubs in this patch.
This is based on Linux commit fb848db39661, written by Andre Przywara.
Andre Przywara [Wed, 7 Feb 2018 13:28:55 +0000 (13:28 +0000)]
ARM: new VGIC: Add MMIO handling framework
Add an MMIO handling framework to the VGIC emulation:
Each register is described by its offset, size (or number of bits per
IRQ, if applicable) and the read/write handler functions. We provide
initialization macros to describe each GIC register later easily.
Separate dispatch functions for read and write accesses are connected
to Xen's MMIO handling framework and binary-search for the responsible
register handler based on the offset address within the region.
The register handler prototype are courtesy of Christoffer Dall.
This is based on Linux commit 4493b1c4866a, written by Marc Zyngier.
Andre Przywara [Wed, 7 Feb 2018 12:37:43 +0000 (12:37 +0000)]
ARM: new VGIC: Implement vgic_vcpu_pending_irq
Tell Xen whether a particular VCPU has an IRQ that needs handling
in the guest. This is used to decide whether a VCPU is runnable or
if a hypercall should be preempted to let the guest handle the IRQ.
This is based on Linux commit 90eee56c5f90, written by Eric Auger.
Andre Przywara [Wed, 7 Feb 2018 12:33:16 +0000 (12:33 +0000)]
ARM: new VGIC: Add GICv2 world switch backend
Processing maintenance interrupts and accessing the list registers
are dependent on the host's GIC version.
Introduce vgic-v2.c to contain GICv2 specific functions.
Implement the GICv2 specific code for syncing the emulation state
into the VGIC registers.
This also adds the hook to let Xen setup the host GIC addresses.
This is based on Linux commit 140b086dd197, written by Marc Zyngier.
Andre Przywara [Wed, 7 Feb 2018 12:26:09 +0000 (12:26 +0000)]
ARM: new VGIC: Add IRQ sync/flush framework
Implement the framework for syncing IRQs between our emulation and the
list registers, which represent the guest's view of IRQs.
This is done in vgic_sync_from_lrs() and vgic_sync_to_lrs(), which
get called on guest entry and exit, respectively.
The code talking to the actual GICv2/v3 hardware is added in the
following patches.
This is based on Linux commit 0919e84c0fc1, written by Marc Zyngier.
Roger Pau Monne [Tue, 27 Mar 2018 15:30:26 +0000 (16:30 +0100)]
kconfig: don't select VPCI if building a shim-only binary
Add dummy replacements for some functions used outside of the vpci
code, and also a guard in vmsi.c to prevent vpci arch specific helpers
from being compiled if the option is not selected.
Reported-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Wed, 28 Mar 2018 11:55:15 +0000 (12:55 +0100)]
libxc/x86: fix mapping of the start_info area
The start_info size calculated in bootlate_hvm is wrong. It should use
HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
take into account the size of the modules command line.
This is not a problem so far because the actually used amount of
memory doesn't cross a page boundary, and so no page-fault is
triggered.
Instead of fixing the size calculation done in bootlate_hvm just map
the amount of memory allocated in alloc_magic_pages_hvm.
Suggested-by: Wei Liu <wei.liu2@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monne [Fri, 23 Mar 2018 12:08:23 +0000 (12:08 +0000)]
SUPPORT.md: add PVH Dom0 status
Also fix x86/HVM to spell out that only DomU HVM mode is supported and
remove the 'guest' from the ARM section, ARM supports both Dom0/DomU
using the same mode.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Anthony PERARD [Mon, 26 Mar 2018 17:38:10 +0000 (18:38 +0100)]
libxl_dm: Replace deprecated -drive if=scsi
.. by -drive if=none,.. -device scsi-disk,...
The use of if=scsi in QEMU is deprecated and has been removed in 2.12 by 1454509726 scsi: Remove automatic creation of SCSI controllers with -drive if=scsi
It used to create a SCSI controller, now we have to explicitly create
it in libxl. This is done ahead of disks creation in order to try to
keep the controller on the PCI slot as it used to be.
The chosen "id" for drive is the same that QEMU used to create.
This patch also take the opportunity to remove the comments in
qemu_disk_scsi_drive_string() which had a typo and is now out of date.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Andre Przywara [Wed, 7 Feb 2018 12:13:36 +0000 (12:13 +0000)]
ARM: new VGIC: Add IRQ sorting
Adds the sorting function to cover the case where you have more IRQs
to consider than you have LRs. We consider their priorities.
This uses the new sort_list() implementation imported from Linux.
This is based on Linux commit 8e4447457965, written by Christoffer Dall.
Andre Przywara [Wed, 7 Feb 2018 12:13:36 +0000 (12:13 +0000)]
Add list_sort() routine from Linux
This pulls in Linux's list_sort.c, which is a merge sort implementation
for linked lists. Apart from adding a full featured license header and
adjusting the #include file, nothing has been changed in this code.
Define a promptless Kconfig which configurations can select when they
need this code and add it to the Makefile.
This is from Linux' lib/list_sort.c, as of commit e327fd7c8667
("lib: add module support to linked list sorting tests").
Signed-off-by: Andre Przywara <andre.przywara@linaro.org> Acked-by: Julien Grall <julien.grall@arm.com>
Andre Przywara [Wed, 7 Feb 2018 12:09:07 +0000 (12:09 +0000)]
ARM: new VGIC: Implement virtual IRQ injection
Provide a vgic_queue_irq_unlock() function which decides whether a
given IRQ needs to be queued to a VCPU's ap_list.
This should be called whenever an IRQ becomes pending or enabled,
either as a result of a hardware IRQ injection, from devices emulated by
Xen (like the architected timer) or from MMIO accesses to the distributor
emulation.
Also provides the necessary functions to allow to inject an IRQ to a guest.
Since this is the first code that starts using our locking mechanism,
we add some (hopefully) clear documentation of our locking strategy and
requirements along with this patch.
This is based on Linux commit 81eeb95ddbab, written by Christoffer Dall.
Andre Przywara [Wed, 7 Feb 2018 11:42:02 +0000 (11:42 +0000)]
ARM: new VGIC: Add accessor to new struct vgic_irq instance
The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a given IRQ
number and (in case of private interrupts) the right VCPU.
This also includes the corresponding put function, which does nothing
for private interrupts and SPIs, but handles the ref-counting for LPIs.
This is based on Linux commit 64a959d66e47, written by Christoffer Dall.
Andre Przywara [Wed, 7 Feb 2018 10:44:49 +0000 (10:44 +0000)]
ARM: new VGIC: Add data structure definitions
Add a new header file for the new and improved GIC implementation.
The big change is that we now have a struct vgic_irq per IRQ instead
of spreading all the information over various bitmaps in the ranks.
We include this new header conditionally from within the old header
file for the time being to avoid touching all the users.
This is based on Linux commit b18b57787f5e, written by Christoffer Dall.
Andre Przywara [Mon, 18 Dec 2017 17:34:24 +0000 (17:34 +0000)]
ARM: vPL011: Use the VGIC's level triggered IRQs handling if available
The emulated ARM SBSA UART is using level triggered IRQ semantics,
however the current VGIC can only handle edge triggered IRQs, really.
Disable the existing workaround for this problem in case we have the
new VGIC in place, which can properly handle level triggered IRQs.
The event channel IRQ has level triggered semantics, however the current
VGIC treats everything as edge triggered.
To correctly process those IRQs, we have to lower the (virtual) IRQ line
at some point in time, depending on whether the interrupt condition
still prevails.
Check the per-VCPU evtchn_upcall_pending variable to make the interrupt
line match its status, and call this function upon every hypervisor
entry.
Andre Przywara [Wed, 3 Jan 2018 17:53:22 +0000 (17:53 +0000)]
ARM: timer: Handle level triggered IRQs correctly
The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we also have to keep track of when the line lowers, as the
emulation depends on it: Upon entering the guest, the new VGIC will
*clear* the virtual interrupt line, so it needs to re-sample the actual
state after returning from the guest.
So we have to sync the state of the interrupt condition at certain
points to catch when the line goes low and we can remove the vtimer vIRQ
from the vGIC (and the LR).
The VGIC in Xen so far only implemented edge triggered vIRQs, really, so
we need to add new functionality to re-sample the interrupt state.
Do this only when the new VGIC is in use.
Alexandru Isaila [Tue, 27 Mar 2018 08:26:42 +0000 (10:26 +0200)]
x86/svm: implement debug events
At this moment the Debug events for the AMD architecture are not
forwarded to the monitor layer.
This patch adds the Debug event to the common capabilities, adds
the VMEXIT_ICEBP then forwards the event to the monitor layer.
Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
exception generated by the single byte INT1
instruction (also known as ICEBP) does not trigger the #DB
intercept. Software should use the dedicated ICEBP
intercept to intercept ICEBP"
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Introduce per-vcpu scheduler operations permission verification.
As long as Xvcpuinfo are in fact scheduler configuration manipulations
there is no need to introduce specific access vectors.
Signed-off-by: Andrii Anisov <andrii_anisov@epam.com> Reviewed-by: Dario Faggioli <dfaggioli@suse.com> Acked-by: Daniel De Graaf <dgegra@tycho.nsa.gov>
Andre Przywara [Thu, 4 Jan 2018 12:38:58 +0000 (12:38 +0000)]
ARM: GIC: Allow reading pending state of a hardware IRQ
To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
Implement a gic_hw_operations member to return the pending state of a
particular interrupt. Due to hardware limitations this only works for
private interrupts of the current CPU, so there is no CPU field in the
prototype.
This adds gicv2/3_peek_irq() helper functions, to read a bit in a bitmap
spread over several MMIO registers.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org> Reviewed-by: Julien Grall <julien.grall@arm.com>
Andre Przywara [Fri, 26 Jan 2018 16:09:44 +0000 (16:09 +0000)]
ARM: GIC: Allow tweaking the active and pending state of an IRQ
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active or pending state of an
interrupt at some point.
To prepare the GIC for that, we introduce a set_active_state() and a
set_pending_state() function to let the VGIC manipulate the state of
an associated hardware IRQ.
This takes care of properly setting the _IRQ_INPROGRESS bit.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org> Reviewed-by: Julien Grall <julien.grall@arm.com>
Andre Przywara [Wed, 21 Mar 2018 13:38:21 +0000 (13:38 +0000)]
ARM: GIC: add GIC_INVALID to enum gic_version
The enum gic_version at the moment just contains GIC_V2 and GIC_V3,
where GIC_V2 happens to map to 0. So without having initialised a
variable of that type, we will read back GIC_V2 (when allocated with zeroing
the memory).
To prevent ambiguities and to give an explicitly uninitialised state, add
a new first member: GIC_INVALID. Also make it obvious that this has a
"0" encoding.
Signed-off-by: Andre Przywara <andre.przywara@linaro.org> Acked-by: Julien Grall <julien.grall@arm.com>
Roger Pau Monné [Mon, 26 Mar 2018 13:17:12 +0000 (15:17 +0200)]
vpci/msix: fix incorrect usage of bitmask
The bitmask to clear the low bits of the address field should be
~0xffffffffull, the current mask clears both the low and the high bits
of the address field, which is a bug.
Reported-by: Coverity Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Fri, 23 Mar 2018 10:57:56 +0000 (10:57 +0000)]
x86/libxc: fix usage of XEN_X86_EMU_ALL after VPCI addition
HVM guest should be created with (XEN_X86_EMU_ALL &
~XEN_X86_EMU_VPCI). This is not an issue for xl/libxl because it
already sets the correct emulation flags and doesn't pass a NULL
xc_domain_configuration_t to xc_domain_create.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Juergen Gross [Fri, 23 Mar 2018 07:42:53 +0000 (08:42 +0100)]
tools/xenstore: fix linking libxenstore with ldl
Commit 448c03b3cbe1487 ("tools/xenstore: try to get minimum thread
stack size for watch thread") added a dependency to libdl to
libxenstore. Unfortunately the way it was added requires now all
users of libxenstore to specify "-ldl" when linking. This can be
avoided by linking libxenstore.so specifying "-ldl" as a trailing
option. So use APPEND_LDFLAGS instead of LDFLAGS for adding the
"-ldl" option when linking libxenstore.so.
Roger Pau Monne [Thu, 22 Mar 2018 14:00:00 +0000 (15:00 +0100)]
vpci: do not expose unneeded functions to the user-space test harness
Some functions in vpci.c (vpci_remove_device and vpci_add_handlers)
are not used by the user-space test harness, so guard them with
__XEN__ in order to avoid exposing them to the user-space test
harness.
Requested-by: Jan Beulich <JBeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Thu, 22 Mar 2018 14:00:00 +0000 (15:00 +0100)]
vpci/msix: add MSI-X handlers
Add handlers for accesses to the MSI-X message control field on the
PCI configuration space, and traps for accesses to the memory region
that contains the MSI-X table and PBA. This traps detect attempts from
the guest to configure MSI-X interrupts and properly sets them up.
Note that accesses to the Table Offset, Table BIR, PBA Offset and PBA
BIR are not trapped by Xen at the moment.
Finally, turn the panic in the Dom0 PVH builder into a warning.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
[IO] Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Roger Pau Monne [Thu, 22 Mar 2018 14:00:00 +0000 (15:00 +0100)]
vpci: add a priority parameter to the vPCI register initializer
This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work properly.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
[ARM] Acked-by: Julien Grall <julien.grall@arm.com>
Roger Pau Monne [Thu, 22 Mar 2018 14:00:00 +0000 (15:00 +0100)]
vpci/msi: add MSI handlers
Add handlers for the MSI control, address, data and mask fields in
order to detect accesses to them and setup the interrupts as requested
by the guest.
Note that the pending register is not trapped, and the guest can
freely read/write to it.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
[IO] Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Roger Pau Monne [Thu, 22 Mar 2018 13:59:00 +0000 (14:59 +0100)]
x86/pt: mask MSI vectors on unbind
When a MSI device with per-vector masking capabilities is detected or
added to Xen all the vectors are masked when initializing it. This
implies that the first time the interrupt is bound to a domain it's
masked.
This however only applies to the first time the interrupt is bound
because neither the unbind nor the pirq unmap will mask the vector
again. In order to fix this re-mask the interrupt when unbinding it
from a guest. This makes sure that pairs of bind/unbind will always
get the same masking state.
Note that no issues have been reported regarding this behavior because
QEMU always uses the newly introduced XEN_PT_GFLAGSSHIFT_UNMASKED when
binding interrupts, so it's always unmasked.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Thu, 22 Mar 2018 14:00:00 +0000 (15:00 +0100)]
vpci: add header handlers
Introduce a set of handlers that trap accesses to the PCI BARs and the
command register, in order to snoop BAR sizing and BAR relocation.
The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangeset is used in order to figure out which memory
to map/unmap. This makes it easier to keep track of the possible
overlaps with other BARs, and will also simplify MSI-X support, where
certain regions of a BAR might be used for the MSI-X table or PBA.
The BAR register handlers are used to detect attempts by the guest to
size or relocate the BARs.
Note that the long running BAR mapping and unmapping operations are
deferred to be performed by hvm_io_pending, so that they can be safely
preempted.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
[IO] Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Roger Pau Monne [Thu, 22 Mar 2018 13:59:00 +0000 (14:59 +0100)]
pci: split code to size BARs from pci_add_device
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Thu, 22 Mar 2018 13:59:00 +0000 (14:59 +0100)]
x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas
Introduce a set of handlers for the accesses to the MMCFG areas. Those
areas are setup based on the contents of the hardware MMCFG tables,
and the list of handled MMCFG areas is stored inside of the hvm_domain
struct.
The read/writes are forwarded to the generic vpci handlers once the
address is decoded in order to obtain the device and register the
guest is trying to access.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Thu, 22 Mar 2018 13:59:00 +0000 (14:59 +0100)]
vpci: introduce basic handlers to trap accesses to the PCI config space
This functionality is going to reside in vpci.c (and the corresponding
vpci.h header), and should be arch-agnostic. The handlers introduced
in this patch setup the basic functionality required in order to trap
accesses to the PCI config space, and allow decoding the address and
finding the corresponding handler that should handle the access
(although no handlers are implemented).
Note that the traps to the PCI IO ports registers (0xcf8/0xcfc) are
setup inside of a x86 HVM file, since that's not shared with other
arches.
A new XEN_X86_EMU_VPCI x86 domain flag is added in order to signal Xen
whether a domain should use the newly introduced vPCI handlers, this
is only enabled for PVH Dom0 at the moment.
A very simple user-space test is also provided, so that the basic
functionality of the vPCI traps can be asserted. This has been proven
quite helpful during development, since the logic to handle partial
accesses or accesses that expand across multiple registers is not
trivial.
The handlers for the registers are added to a linked list that's keep
sorted at all times. Both the read and write handlers support accesses
that expand across multiple emulated registers and contain gaps not
emulated.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
[IO parts] Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
[ARM] Acked-by: Julien Grall <julien.grall@arm.com>
[Tools] Acked-by: Wei Liu <wei.liu2@citrix.com>
Jan Beulich [Thu, 22 Mar 2018 17:02:19 +0000 (18:02 +0100)]
x86emul: fix #XM delivery typo
This clearly wasn't meant the way it was originally written.
Reported-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 22 Mar 2018 09:43:54 +0000 (10:43 +0100)]
x86/shadow: fold sh_x86_emulate_{write,cmpxchg}() into their only callers
The functions have a single caller only and are now guest paging type
independent (except for the tracing part), so have no need to exist as
standalone ones, let alone multiple times. Replace the two prior hooks
with just a single one for dealing with tracing.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
Jan Beulich [Thu, 22 Mar 2018 09:43:21 +0000 (10:43 +0100)]
x86/shadow: fully move unmap-dest into common code
By adding guest PTE size to shadow emulation context, the work begun by
commit 2c80710a78 ("x86/shadow: compile most write emulation code just
once") can be completed, paving the road for further movement into
common code.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
Jan Beulich [Thu, 22 Mar 2018 09:42:31 +0000 (10:42 +0100)]
x86/HVM: use x86emul_write_xcr()
... instead of directly calling handle_xsetbv(), to make use of the
additional checking there.
Also don't call hvm_monitor_crX(XCR0, ...) for indexes other than zero
anymore.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Thu, 22 Mar 2018 09:41:37 +0000 (10:41 +0100)]
x86/HVM: make use of new read-modify-write emulator hook
..., at least as far as currently possible, i.e. when a mapping can be
obtained.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
projects / xen.git / log