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>
Jan Beulich [Thu, 22 Mar 2018 09:39:32 +0000 (10:39 +0100)]
x86emul: add read-modify-write hook
In order to correctly emulate read-modify-write insns, especially
LOCKed ones, we should not issue reads and writes separately. Use a
new hook to combine both, and don't uniformly read the memory
destination anymore. Instead, DstMem opcodes without Mov now need to
have done so in their respective case blocks.
Also strip bogus _ prefixes from macro parameters when this only affects
lines which are being changed anyway.
In the test harness, besides some re-ordering to facilitate running a
few tests twice (one without and a second time with the .rmw hook in
place), tighten a few EFLAGS checks and add a test for NOT with memory
operand (in particular to verify EFLAGS don't get altered there).
For now make use of the hook optional for callers; eventually we may
want to consider making this mandatory.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
If the ->cmpxchg() hook finds a mismatch, we should deal with this the
same way as when the "manual" comparison reports a mismatch.
This involves reverting bfce0e62c3 ("x86/emul: Drop
X86EMUL_CMPXCHG_FAILED"), albeit with X86EMUL_CMPXCHG_FAILED now
becoming a value distinct from X86EMUL_RETRY.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
Jan Beulich [Thu, 22 Mar 2018 09:38:02 +0000 (10:38 +0100)]
x86emul: tell cmpxchg hook whether LOCK is in effect
This is necessary for the hook to correctly perform the operation.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
Jan Beulich [Thu, 22 Mar 2018 09:36:55 +0000 (10:36 +0100)]
x86emul: adjust_bnd() should check XCR0
Experimentally MPX instructions have been confirmed to behave as NOPs
unless both related XCR0 bits are set to 1. By implication branches
then also don't clear BNDn.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 22 Mar 2018 09:35:50 +0000 (10:35 +0100)]
x86emul: abstract out XCRn accesses
Use hooks, just like done for other special purpose registers.
This includes moving XCR0 checks from hvmemul_get_fpu() to the emulator
itself as well as adding support for XGETBV emulation.
For now fuzzer reads will obtain the real values (minus the fuzzing of
the hook pointer itself).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com> [tracing parts]
Doug Goldstein [Thu, 15 Mar 2018 15:54:04 +0000 (10:54 -0500)]
ci: add new bits to MAINTAINERS combine with Travis
Created a new section just called 'CI' since this is adding GitLab CI
and still leaving the old Travis CI files around. This consolidates the
two sections and adds the new files as well as adding another Travis
file that was missing.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Doug Goldstein [Sun, 11 Mar 2018 06:08:50 +0000 (00:08 -0600)]
ci: use GitLab CI to build
Added a GitLab CI config which has a lot more flexibility to allow us to
test a lot more distro configurations than Travis can and even build
test on FreeBSD. This includes a modified copy of scripts/travis-build
that is expected to diverge future over time as we build more than what
Travis is currently building.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Doug Goldstein [Wed, 14 Mar 2018 16:23:31 +0000 (11:23 -0500)]
ci: add Dockerfile for Debian stretch
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Debian stretch system.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Doug Goldstein [Tue, 13 Mar 2018 02:32:27 +0000 (21:32 -0500)]
ci: add Dockerfile for Debian jessie
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Debian jessie system.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Doug Goldstein [Mon, 12 Mar 2018 17:45:00 +0000 (12:45 -0500)]
ci: add Dockerfile for Ubuntu 16.04
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Ubuntu 16.04 system.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Doug Goldstein [Mon, 12 Mar 2018 17:41:33 +0000 (12:41 -0500)]
ci: add Dockerfile for Ubuntu 14.04
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a Ubuntu 14.04 system.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Doug Goldstein [Mon, 12 Mar 2018 17:40:45 +0000 (12:40 -0500)]
ci: add Dockerfile for CentOS 7.2
Added a Dockerfile which captures all the necessary dependencies to
build Xen on a CentOS 7.2 system.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
projects / xen.git / log