Jan Beulich [Thu, 15 Nov 2018 15:43:36 +0000 (16:43 +0100)]
x86/shadow: emulate_gva_to_mfn() should respect p2m_ioreq_server
Writes to such pages need to be handed to the emulator.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Tim Deegan <tim@xen.org>
Jan Beulich [Thu, 15 Nov 2018 15:42:25 +0000 (16:42 +0100)]
x86/HVM: __hvm_copy() should not write to p2m_ioreq_server pages
Commit 3bdec530a5 ("x86/HVM: split page straddling emulated accesses in
more cases") introduced a hvm_copy_to_guest_linear() attempt before
falling back to hvmemul_linear_mmio_write(). This is wrong for the
p2m_ioreq_server special case. That change widened a pre-existing issue
though: Other writes to such pages also need to be failed (or forced
through emulation), in particular hypercall buffer writes.
Reported-by: Igor Druzhinin <igor.druzhinin@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Wei Liu [Fri, 9 Nov 2018 11:23:46 +0000 (11:23 +0000)]
xen: report PV capability in sysctl and use it in toolstack
0e2c886ef ("xen: decouple HVM and IOMMU capabilities") provided a
truth table for what `xl info` would report. In order to make the
table work xen will need to report its PV capability.
Replace cap_directio with cap_pv in libxl IDL. It is safe to do so
because cap_directio has never been released. Revert to use
cap_hvm_directio to mark the availability of IOMMU, to save us from
providing a compatibility layer.
Don't bump sysctl version number because we've already done so.
Also provide a new virt_caps "pv", change "directio" to "pv_directio".
The truth table is now:
Jan Beulich [Thu, 15 Nov 2018 12:36:52 +0000 (13:36 +0100)]
x86/HVM: hvmemul_cmpxchg() should also use known_gla()
To be consistent with the write and rmw cases the mapping approach
should not be used when the guest linear address translation is known.
This in particular excludes the discard-write case from bypassing the
emulation path. This also means that now EFLAGS should actually get
properly updated, despite the discarded write portion of the memory
access.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Jan Beulich [Thu, 15 Nov 2018 12:36:10 +0000 (13:36 +0100)]
x86/HVM: make hvmemul_map_linear_addr() honor p2m_ioreq_server
Write accesses to p2m_ioreq_server pages should get redirected to the
emulator also when using the mapping approach. Extend the
p2m_is_discard_write() check there, and restrict both to the write
access case (this is just a latent bug as currently we go this route
only for write accesses).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Razvan Cojocaru [Thu, 15 Nov 2018 12:35:08 +0000 (13:35 +0100)]
x86/altp2m: propagate ept.ad changes to all active altp2ms
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime).
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will inherit the hostp2m's
ept.ad value.
The p2m_{en,dis}able_hardware_log_dirty() hostp2m locking has
been moved to the new ept_{en,dis}able_hardware_log_dirty()
functions as part of the code refactoring, while locks for the
individual altp2ms are taken in ept_set_ad_sync() (called by
ept_{en,dis}able_pml()).
Suggested-by: George Dunlap <george.dunlap@citrix.com> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com> Tested-by: Tamas K Lengyel <tamas@tklengyel.com> Acked-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Thu, 15 Nov 2018 12:34:21 +0000 (13:34 +0100)]
IOMMU/x86: remove indirection from certain IOMMU hook accesses
There's no need to go through an extra level of indirection. In order to
limit code churn, call sites using struct domain_iommu's platform_ops
don't get touched here, however.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Brian Woods <brian.woods@amd.com>
Jan Beulich [Thu, 15 Nov 2018 12:32:47 +0000 (13:32 +0100)]
IOMMU: move inclusion point of asm/iommu.h
In preparation of allowing inline functions in asm/iommu.h to
de-reference struct struct iommu_ops, move the inclusion downwards past
the declaration of that structure. This in turn requires moving the
struct domain_iommu declaration, as it requires struct arch_iommu to be
fully declared beforehand.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <julien.grall@arm.com>
Andrew Cooper [Tue, 2 Oct 2018 19:10:27 +0000 (20:10 +0100)]
Revert "xen/arm: vgic-v3: Delay the initialization of the domain information"
This reverts commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db. The domain
creation logic has been adjusted to set up d->max_vcpus early enough to be
usable in vgic_v3_domain_init().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com>
Andrew Cooper [Tue, 2 Oct 2018 14:02:55 +0000 (14:02 +0000)]
xen/domain: Allocate d->vcpu[] earlier during domain_create()
The ARM code has a chicken-and-egg problem. One of the vGICv3 emulations
wants to know d->max_vcpus to be able to size itself appropriately, but the
current order of initialisation requires the vGIC to be set up before the
requested number of vcpus can be checked.
Move the range checking of config->max_vcpus into sanitise_domain_config()
path, which allows for the allocation of d->vcpu[] and d->max_vcpus to happen
earlier during create, and in particular, before the call to
arch_domain_create().
The x86 side is fairly easy, and implements the logical equivalent of
domain_max_vcpus() but using XEN_DOMCTL_CDF_hvm_guest rather than
is_hvm_domain().
For the ARM side, re-purpose vgic_max_vcpus() to take a domctl vGIC version,
and return the maximum number of supported vCPUs, reusing 0 for "version not
supported". To avoid exporting the vgic_ops structures (which are in the
process of being replaced), hard code the upper limits.
This allows for the removal of the domain_max_vcpus() infrastructure, which is
done to prevent it being reused incorrectly in the future.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <julien.grall@arm.com>
Andrew Cooper [Fri, 9 Nov 2018 18:55:59 +0000 (18:55 +0000)]
xen/domain: Move guest type checks into the arch_sanitise_domain_config() path
This is a more appropriate location for the checks to happen, and cleans up
the common code substantially.
Take the opportunity to make ARM strictly require HVM|HAP for guests, which is
how the toolstack behaves, and leave a dprintk() behind for auditing failures.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Make vpl011 being able to be used without a userspace component in Dom0.
In that case, output is printed to the Xen serial and input is received
from the Xen serial one character at a time.
Call domain_vpl011_init during construct_domU if vpl011 is enabled.
Introduce a new ring struct with only the ring array to avoid a waste of
memory. Introduce separate read_data and write_data functions for
initial domains: vpl011_write_data_xen is very simple and just writes
to the console, while vpl011_read_data_xen is a duplicate of
vpl011_read_data. Although textually almost identical, we are forced to
duplicate the functions because the struct layout is different.
To avoid mixing the output of different domains on the console, buffer
the output chars and print line by line. Unless the domain has input
from the serial, in which case we want to print char by char for a
smooth user experience.
The size of SBSA_UART_OUT_BUF_SIZE is arbitrary, choose the same size
as VUART_BUF_SIZE used in vuart.c.
Export a function named console_input_domain() to allow others to know
which domains has input at a given time.
xen: support console_switching between Dom0 and DomUs on ARM
Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
mechanism to allow for switching between Xen, Dom0, and any of the
initial DomU created from Xen alongside Dom0 out of information provided
via device tree.
Rename xen_rx to console_rx to match the new behavior.
Clarify existing comment about "notify the guest", making it clear that
it is only about the hardware domain.
Switching the console input to domUs started from Xen at boot is
#ifdef'ed to 0 in this patch. The code will be enabled when
vpl011_rx_char_xen is introduced. For now it is disabled for
bisectability.
Move the code to calculate in_fifo_level and out_fifo_level out of
vpl011_data_avail, to the caller.
This change will make it possible to reuse vpl011_data_avail with
different ring structures in a later patch.
Introduce a union in struct vpl011 to contain the console ring members.
A later patch will add another member of the union for the case where
the backend is in Xen.
xen/arm: generate vpl011 node on device tree for domU
Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.
The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.
Enable vpl011 conditionally if the user requested it.
Call a new function, "create_domUs", from setup_xen to start DomU VMs.
Introduce support for the "xen,domain" compatible node on device tree.
Create new DomU VMs based on the information found on device tree under
"xen,domain". Call construct_domU for each domain.
Introduce a simple global variable named max_init_domid to keep track of
the initial allocated domids. It holds the max domid among the initial
domains.
Move the discard_initial_modules after DomUs have been built.
First create domUs, then start dom0 -- no point in trying to start dom0
when the cpu is busy.
xen/arm: move unregister_init_virtual_region to init_done
Move unregister_init_virtual_region to init_done. Follow the same path
as x86. It is also useful to move it later so that create_domUs can be
called before that in following patches.
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
Add a new start address field to struct bootcmdline to easily match a
cmdline to the corresponding bootmodule. This is useful for debugging
(not actually needed for functionalities today, but could be.)
Instead of printing the index in the cmdline array, print the start
address of the corresponding bootmodule for each cmdline in
early_print_info.
Find addresses, sizes on device tree from kernel_probe.
Find the cmdline from the bootcmdlines array.
Introduce a new boot_module_find_by_addr_and_kind function to match not
just on boot module kind, but also by address so that we can support
multiple domains.
Introduce a boot_cmdline_find_by_name function to find the right struct
cmdline based on the device tree node name of the "xen,domain"
compatible node.
Set command line for dom0 in kernel_probe for consistency.
xen/arm: don't add duplicate boot modules, introduce domU flag
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks of "xen,domain" nodes to avoid getting
confused in kernel_probe, where we try to guess which is the dom0 kernel
and initrd to be compatible with all versions of the multiboot spec.
boot_module_find_by_kind and boot_cmdline_find_by_kind automatically
check for !domU entries (they are only used for non-domU modules).
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (important because we want them to be
free'd only once), but they can still have their separate bootcmdline
entries.
Add a dt_name field to struct bootcmdline to make it easier to find the
correct entry. Store the name of the "xen,domain" compatible node (for
example "Dom1"). This is a better choice compared to the name of the
"multiboot,kernel" compatible node, because their names are not unique.
For instance there can be more than one "module@0x4c000000" in the
system, but there can only be one "/chosen/Dom1".
Add a pointer to struct kernel_info to point to the cmdline for a given
kernel.
Xen boot modules need to account not just for Dom0 but also for a few
potential DomUs, each of them coming with their own kernel and initrd.
Increase MAX_MODULES to 32 to allow for more DomUs.
xen: allow console_io hypercalls from certain DomUs
Introduce an is_console option to allow certain classes of domUs to use
the Xen console. Specifically, it will be used to give console access to
all domUs started from Xen from information on device tree.
Signed-off-by: Stefano Stabellini <stefanos@xilinx.com> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Jan Beulich <jbeulich@suse.com> CC: andrew.cooper3@citrix.com CC: George.Dunlap@eu.citrix.com CC: ian.jackson@eu.citrix.com CC: jbeulich@suse.com CC: konrad.wilk@oracle.com CC: tim@xen.org CC: wei.liu2@citrix.com CC: dgdegra@tycho.nsa.gov
Sergey Dyasli [Wed, 14 Nov 2018 10:23:22 +0000 (10:23 +0000)]
x86/vvmx: correctly report vvmcs size
The size of Xen's virtual vmcs region is 4096 bytes (see comment about
Virtual VMCS layout in include/asm-x86/hvm/vmx/vvmx.h). Correctly report
it to the guest in case when VMCS shadowing is not available instead of
providing H/W value (which is usually smaller).
Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Sergey Dyasli [Wed, 14 Nov 2018 10:23:16 +0000 (10:23 +0000)]
x86/nestedhvm: init nv_vvmcxaddr in hvm_vcpu_initialise()
This allows to safely use nestedhvm functions that rely on the values
inside struct nestedvcpu independently of the nested virtualisation
(HVM_PARAM_NESTEDHVM) status of a domain.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Sergey Dyasli <sergey.dyasli@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 8 Nov 2018 18:12:19 +0000 (18:12 +0000)]
x86/hvm: Unify hvm_event_pending()'s API with the !CONFIG_HVM version
This patch should have been part of, or a prerequiesite of, c/s 981c9a78 "x86:
provide stubs, declarations and macros in hvm.h" to avoid getting the API's
out of sync.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Wed, 14 Nov 2018 16:50:18 +0000 (17:50 +0100)]
x86: add myself as reviewer
As I've touched quite a lot of this code in order to add PVH and PV
shim support I would like to keep an eye on incoming changes, and
since I'm also attempting to review patches in this area it's going to
be easier if I get CCed on them.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Christian Lindig [Wed, 14 Nov 2018 11:06:49 +0000 (11:06 +0000)]
tools/ocaml: cleanup to reduce compiler warnings
This commit cleans up code to reduce compiler warnings:
* remove unused open statements (warning 33)
* remove unused 'rec' declarations (warnign 39)
* remove unused type declarations (warning 34)
* mark unused variables with an underscore (warning 27)
* mark unused value declarations with an underscore (warning 32)
This commit does not include changes to fix compiler warnings 52
(matching against strings in exceptions). These changes have no impact
on functionality.
Signed-off-by: Christian Lindig <christian.lindig@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
This patch adds a couple of regs to the vm_event that are used by
the introspection. The base, limit and ar
bits are compressed into a uint64_t union so as not to enlarge the
vm_event.
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Daniel De Graaf [Fri, 2 Nov 2018 17:46:11 +0000 (13:46 -0400)]
flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Roger Pau Monné [Mon, 12 Nov 2018 16:14:57 +0000 (17:14 +0100)]
guest/pvh: special case the low 1MB
When running as a PVH guest Xen only special cases the trampoline
code in the low 1MB, without also reserving the space used by the
relocated metadata or the trampoline stack.
Fix this by always reserving the low 1MB regardless of whether Xen is
running as a guest or natively.
Reported-by: Sergey Dyasli <sergey.dyasli@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Roger Pau Monné [Mon, 12 Nov 2018 16:13:57 +0000 (17:13 +0100)]
guest/pvh: fix handling of multiboot module list
When booting Xen as a PVH guest the data in the PVH start info
structure is copied over to a multiboot structure and a module list
array that resides in the .init section of the Xen image. The
resulting multiboot module list is then handed to the generic boot
process using the physical address in mbi->mods_addr.
This works fine as long as the Xen image doesn't relocate itself, if
there's such a relocation the physical addresses of multiboot module
list is no longer valid.
Fix this by handing the virtual address of the module list to the
generic boot process instead of it's physical address.
Reported-by: Sergey Dyasli <sergey.dyasli@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Julien Grall [Tue, 23 Oct 2018 14:25:13 +0000 (15:25 +0100)]
xen/arm: gic: Relax barrier when sending an SGI
When sending an SGI to another CPU, we require a barrier to ensure that
any pending stores to normal memory are made visible to the recipient
before the interrupt arrives.
For GICv2, rather than using dsb(sy) before writel_gicd, we can instead
use dsb(ishst), since we just need to ensure that any pending normal
writes are visible within the inner-shareable domain before we poke the
GIC.
With this observation, we can then further weaken the barrier to a
dmb(ishst), since other CPUs in the inner-shareable domain must observe
the write to the distributor before the SGI is generated.
A DMB instruction can be used to ensure the relative order of only
memory accesses before and after the barrier. Since writes to system
registers are not memory operations, barrier DMB is not sufficient for
observalibility of memory accesses that occur before ICC_SGI1R_EL1
(GICv3).
For GICv3, a DSB instruction ensures that no instructions that appear in
program order after the DSB instruction, can execute until the DSB
instruction has completed.
Andrew Cooper [Fri, 9 Nov 2018 14:14:08 +0000 (14:14 +0000)]
x86/dom0: Avoid using 1G superpages if shadowing may be necessary
The shadow code doesn't support 1G superpages, and will hand #PF[RSVD] back to
guests.
For dom0's with 512GB of RAM or more (and subject to the P2M alignment), Xen's
domain builder might use 1G superpages.
Avoid using 1G superpages (falling back to 2M superpages instead) if there is
a reasonable chance that we may have to shadow dom0. This assumes that there
are no circumstances where we will activate logdirty mode on dom0.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Julien Grall [Tue, 23 Oct 2018 18:17:07 +0000 (19:17 +0100)]
xen/arm: gic: Ensure ordering between read of INTACK and shared data
When an IPI is generated by a CPU, the pattern looks roughly like:
<write shared data>
dsb(sy);
<write to GIC to signal SGI>
On the receiving CPU we rely on the fact that, once we've taken the
interrupt, then the freshly written shared data must be visible to us.
Put another way, the CPU isn't going to speculate taking an interrupt.
Unfortunately, this assumption turns out to be broken.
Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy
to read some shared_data. Before CPUx has done anything, a random
peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised.
CPUy then takes the IRQ and starts executing the entry code, heading
towards gic_handle_irq. Furthermore, let's assume that a bunch of the
previous interrupts handled by CPUy were SGIs, so the branch predictor
kicks in and speculates that irqnr will be <16 and we're likely to
head into handle_IPI. The prefetcher then grabs a speculative copy of
shared_data which contains a stale value.
Meanwhile, CPUx gets round to updating shared_data and asking the GIC
to send an SGI to CPUy. Internally, the GIC decides that the SGI is
more important than the peripheral interrupt (which hasn't yet been
ACKed) but doesn't need to do anything to CPUy, because the IRQ line
is already raised.
CPUy then reads the ACK register on the GIC, sees the SGI value which
confirms the branch prediction and we end up with a stale shared_data
value.
This patch fixes the problem by adding an smp_rmb() to the IPI entry
code in do_SGI.
Julien Grall [Tue, 23 Oct 2018 18:17:06 +0000 (19:17 +0100)]
xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()
Devices that expose their interrupt status registers via system
registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
vgic (although unused by Linux), ...) rely on a context synchronising
operation on the CPU to ensure that the updated status register is
visible to the CPU when handling the interrupt. This usually happens as
a result of taking the IRQ exception in the first place, but there are
two race scenarios where this isn't the case.
For example, let's say we have two peripherals (X and Y), where Y uses a
system register for its interrupt status.
Case 1:
1. CPU takes an IRQ exception as a result of X raising an interrupt
2. Y then raises its interrupt line, but the update to its system
register is not yet visible to the CPU
3. The GIC decides to expose Y's interrupt number first in the Ack
register
4. The CPU runs the IRQ handler for Y, but the status register is stale
Case 2:
1. CPU takes an IRQ exception as a result of X raising an interrupt
2. CPU reads the interrupt number for X from the Ack register and runs
its IRQ handler
3. Y raises its interrupt line and the Ack register is updated, but
again, the update to its system register is not yet visible to the
CPU.
4. Since the GIC drivers poll the Ack register, we read Y's interrupt
number and run its handler without a context synchronisation
operation, therefore seeing the stale register value.
In either case, we run the risk of missing an IRQ. This patch solves the
problem by ensuring that we execute an ISB in the GIC drivers prior
to invoking the interrupt handler.
Julien Grall [Wed, 31 Oct 2018 18:13:13 +0000 (18:13 +0000)]
xen/arm: Move vgic_* helpers from gic.h to vgic.h
Keep vgic_* helpers in a single place. At the same time remove gic.h
from event.h since the helpers has now been moved to vgic.h (included by
domain.h).
Julien Grall [Wed, 31 Oct 2018 18:13:02 +0000 (18:13 +0000)]
xen/arm: Move SYSREG accessors in sysregs.h
System registers accessors are self-contained and should not be included
everywhere in Xen. Move the accessors in sysregs.h and include the file
when necessary.
With that change, it is not necessary to include processor.h in time.h.
Julien Grall [Wed, 31 Oct 2018 18:12:57 +0000 (18:12 +0000)]
xen/arm: Consolidate CPU identification in cpufeature.{c,h}
At the moment, CPU Identification is spread accross cpu.c, cpufeature.c,
processor.h, cpufeature.h. It would be better to keep everything
together in a single place.
Julien Grall [Wed, 31 Oct 2018 18:12:55 +0000 (18:12 +0000)]
xen/arm: Remove __init from prototype
In Xen, it is common to add __init to the declaration and not the
prototype. Remove the few __init on some prototypes which allows to
avoid the inclusion of init.h in headers.
With these changes, init.h is now required to be included on some c
files. Also, add __init where it was missing in declaration.
x86/hvm: clean up the rest of bool_t from vm_event
Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: George Dunlap <george.dunlap@citrix.com>
Jan Beulich [Fri, 9 Nov 2018 12:05:28 +0000 (13:05 +0100)]
pass-through: adjust pIRQ migration
For one it is quite pointless to iterate over all pIRQ-s the domain has
when just one is being adjusted. Introduce hvm_migrate_pirq() as an
externally accessible function.
Additionally it is bogus to migrate the pIRQ to a vCPU different from
the one the event is supposed to be posted to - if anything, it might be
worth considering not to migrate the pIRQ at all in the posting case.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Julien Grall [Thu, 1 Nov 2018 10:16:58 +0000 (10:16 +0000)]
xen/grant_table: Remove stale comment on top of map_grant_ref
Remove the 2 part comment on top of map_grant_ref:
- The first part mention the return value which has been void since
2006!
- The second part mention a local variable 'addr' which does not
exist anymore.
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
projects / people / dariof / xen.git / log