While doing so also take care of #VE here (even if we don't make use of
it yet). Note that contributory_exceptions, other than the original
0x7c01 constant, doesn't include #PF anymore, but the check where the
variable is used is after one that already filtered out #PF.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: TIm Deegan <tim@xen.org>
It using CLZ on a 64-bit register while specifying the input operand as
only 32 bits wide is wrong: An operand intentionally shrunk down to 32
bits at the source level doesn't imply respective zero extension also
happens at the machine instruction level, and hence the wrong result
could get returned.
Add suitable inline assembly abstraction so that the function can
remain shared between arm32 and arm64. The need to include asm_defns.h
in bitops.h makes it necessary to adjust processor.h though - it is
generally wrong to include public headers without making sure that
integer types are properly defined. (I didn't innvestigate or try
whether the possible alternative of moving the public/arch-arm.h
inclusion down in the file would also work.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Their parameter types differed between ARM and x86.
Along with generalizing the functions this fixes
- x86's non-long functions having long parameter types
- ARM's ffs() using a long intermediate variable
- generic_fls64() being broken when the upper half of the input is
non-zero
- common (and in one case also ARM) code using fls() when flsl() was
meant
Also drop ARM's constant_fls() in favor of the identical generic_fls().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The x2apic MSR space is currently defined between 0x800 and 0x83f, which
conveniently fits in a 64 bit wide bitmap. This is far more efficient than
the cascade comparisons generated by the switch statement, which can't be
optimised because of the case ranges used for the ISR, TMR and IRR blocks.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Convert 0xffUL to ((1UL << (NR_VECTORS / 32)) - 1) and drop a couple of
clearly superfluous parentheses.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Both are called with known-good domains, making the NULL check redundant.
Both also have open-coded forms of for_each_vcpu() which are replaced.
switch_compat() is updated to propagate the error from set_compat_l4(), rather
than automatically overriding with -ENOMEM.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Most of them have been unused since the dropping of 32-bit support, and
the few remaining cases are more efficiently dealt with using a generic
macro (and probably things should have been done that way from the
beginning).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
A few relevant control state fields did not get dumped so far; in
particular, VM_ENTRY_INSTRUCTION_LEN got printed twice (instead of also
printing VM_EXIT_INSTRUCTION_LEN). Where suitable (to reduce the amount
of output) make some of the dumping conditional upon guest settings
(this isn't required for correctness as vmr() already uses
__vmread_safe(), i.e. it is fine to access non-existing fields).
Also drop casts.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
A few host state fields did not get dumped so far. Where suitable (to
reduce the amount of output) make some of the dumping conditional upon
guest settings (this isn't required for correctness as vmr() already
uses __vmread_safe(), i.e. it is fine to access non-existing fields).
Also drop casts - many of them haven't been needed anymore since the
dropping of 32-bit support.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Several guest state fields did not get dumped so far. Where suitable
(to reduce the amount of output) make some of the dumping conditional
upon guest settings (this isn't required for correctness as vmr()
already uses __vmread_safe(), i.e. it is fine to access non-existing
fields).
Move CR3_TARGET_* and TSC_OFFSET processing into the control state
section, at once making the upper bound of CR3_TARGET_VALUEn printed
depend on CR3_TARGET_COUNT (which architecturally can be higher than
4).
Also rename GUEST_PDPTRn to GUEST_PDPTEn (matching the SDM naming) and
group them as well as CR3_TARGET_VALUEn similar to EOI_EXIT_BITMAP.
Finally, drop casts - they haven't been needed anymore since the
dropping of 32-bit support (and some of them were not really needed in
the first place). Introduce vmr16() and vmr32() helper macros to avoid
the "l" printk format modifier and at the same time validate that only
16-/32-bit fields get accessed this way.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Only the low 32 bits are relevant.
For consistency also change a cast on regs->eax to regs->_eax.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
As done by the recent Linux commit b65d6e17fe ("kvm: x86: mask out
XSAVES") for KVM, we should also mask out XSAVES from what PV guests
get to see as long as we don't emulate accesses to MSR_IA32_XSS.
Actually, go beyond that: Just like for leaf 7, switch from
blacklisting to whitelisting, i.e. only allow XSAVEOPT and XSAVEC for
the time being. And do these overrides consistently for both Dom0 and
DomU-s.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In all 4 cases, visible in the context are bounds check against d->max_vcpus.
Domain building will ensure that d->max_vcpus never exceeds an appropriate
bound. In the x86 case, different types of domains have different maxima for
vcpus, making the checks wrong as opposed to simply redundant.
For vpsci in ARM, 'vcpuid' is an unsigned type so could never be less than 0.
For the common changes to do_{,compat}_vcpu_op(), these changes do result in a
guest visible change, but only in so far as certain invalid vcpu ids will now
fail with -ENOENT rather than -EINVAL.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The arinc653 interface is capable of specifying a domain in the schedule (from
the toolstack) before the domain itself exists, or is present in the cpupool
(The domain is identified by UUID rather than domid). As a result, the
schedule can't be validated at this point.
The vcpu_id from userspace is only ever used to compare against a list of real
vcpus available to the scheduler, which prevents ill-specified vcpus from
actually being scheduled.
Remove the MAX_VIRT_CPUS test, as it is not an appropriate bound for vcpu_id.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by Robert VanVossen <robert.vanvossen@dornerworks.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Use domain_max_vcpus(d) in preference to MAX_VIRT_CPUS when allocating the
poll mask. This allows x86 HVM guests to have a poll mask of 128 bits rather
than 8k bits.
While changing this, use xzalloc_array() in preference to xmalloc_array() to
avoid needing the subsequent call to bitmap_zero().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This allows the common XEN_DOMCTL_max_vcpus handler to lose some x86-specific
architecture knowledge.
It turns out that Xen had the same magic number twice in-tree with different
names (HVM_MAX_VCPUS and MAX_HVM_VCPUS). This removes all use of
MAX_HVM_VCPUS, and x86 uses HVM_MAX_VCPUS from the public headers.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Now that we have two cases where patches against hvmloader got
submitted needing to include the hypervisor's errno.h (for the host's
system header not necessarily reflecting the correct numbers), take
this as a strong sign that we need to make the error return values part
of the hypervisor ABI (which de-fact they've always been).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
... to reduce padding holes.
I also wonder whether having independent spin locks side by side is
really a good thing cache-line-bouncing-wise.
Also change suspend_evtchn's type to evtchn_port_t.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Tim Deegan <tim@xen.org>
... and drop global latching of current, as being needed more than once
only in PHYSDEVOP_set_iopl and PHYSDEVOP_set_iobitmap, and not at all
in all other cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
We don't really need the MFN in more than one place (after dropping
mfn_to_page() translations where we know the result already), so no
need to have a local variable for it.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Xen event channels are not internal resources. They still have one end in a
domain, and are created at the request of privileged domains. This logic
which "successfully" creates a Xen event channel opens up undesirable failure
cases with ill-specified XSM policies.
If a domain is permitted to create ioreq servers or memevent listeners, but
not to create event channels, the ioreq/memevent creation will succeed but
attempting to bind the returned event channel will fail without any indication
of a permission error.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
About half of the cpuid space has the top bit of op set, and op it always
specified with unsigned integers. There are no problematic uses in tree at
the moment.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
QEMU upstream requires the use of pixman. When pixman is not present the
system, the configure of QEMU will fail with:
ERROR: pixman not present. Your options:
(1) Preferred: Install the pixman devel package (any recent
distro should have packages as Xorg needs pixman too).
(2) Fetch the pixman submodule, using:
git submodule update --init pixman
I think we can use by default the version on the system. So check it
a Xen configuration time to avoid a build issue later.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- reran autogen.sh, adjusted comment ]
The field nr_lines in the arch_domain vgic structure contains the number of
SPIs for the emulated GIC. Using the nr_lines make confusion with the GIC
code, where it means the number of IRQs. This can lead to coding error.
Also introduce vgic_num_irqs to get the number of IRQ handled by the emulated
GIC.
Finally drop the initialization of nr_spis in both gicv2v_init and gicv3_init
as it's already initialized in vgic common code.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
A pkg-config file for libxl. It also contains two variables
(xenfirmwaredir and libexec_bin) so that tools that are very keen on
knowing the locations of Xen binaries (say, libvirt) can use them to
determine the location of the binaries.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran autogen.sh ]
HVM guests have always been confined to using the domain callback
via (see HVM_PARAM_CALLBACK_IRQ) to receive event notifications.
This is usually an IOAPIC vector and is only used if the event
channel is bound to vcpu 0.
PVHVM Linux uses a pre-defined interrupt vector for the event
channel upcall, set using HVM_PARAM_CALLBACK_IRQ by ORing in a
special bit (bit 57) into the value (see params.h). However, it
does not assert the interrupt via the emulated local APIC.
This mechanism is not suitable in the general case since Windows
(and potentially other OSes) because they:
- cannot guarantee the same vector for all VCPUs
- do require the upcall to be asserted via the local APIC
This patch adds a new HVM op allowing a guest to specify a local
APIC vector to use as an upcall notification for a specific vcpu
therefore coping with the case of differing vector numbers.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
MiniOS has never advertised support for supervisor_mode_kernel, and the
feature was only ever implemented for 32bit Xen.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
c/s 3f8e22de7 "x86 hvm: Allow HPET to be configured as a per-domain config
option" introduced the parameter to conditionally enable the HPET.
However, having the check in hpet_range() does not have the intended effect.
As currently implemented, when the HPET is disabled, the range is not claimed
and an ioreq is forwarded to qemu, which implements an HPET itself.
Properly disable the HPET by always claiming the range, dropping writes and
reading ~0.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
crashinfo_maxaddr can/will be a 64-bit type, hence passing it to fls()
is wrong.
crashinfo_maxaddr_bits, otoh, doesn't need to be a paddr_t, and can
additionally be __initdata.
struct xen_kexec_reserve's start field - representing a physical
address - ought to have respective type.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
The trivial wrapper evtchn_set_pending() is pretty pointless, as it
only serves to invoke another wrapper evtchn_port_set_pending(). In
turn, the latter is kind of inconsistent with its siblings in that is
takes a struct vcpu * rather than a struct domain * - adjusting this
allows for more efficient code in the majority of cases.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Tim Deegan <tim@xen.org>
XENMEM_{in,de}crease_reservation as well as XENMEM_populate_physmap
return the extent at which failure was detected, not error indicators.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Tim Deegan <tim@xen.org>
Minor updates to the documentation in xen/include/public/arch-arm.h:
- Comments coding style fix
- Typoes
- Update the list of supported hypercalls by ARM
- Remove unnecessary comment about 64bit.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- fixed spelling of unnecessary, corrected aarch into aarch32 ]
This was disabled by default in Xen 4.4. Since xend has now been
removed from the tree I don't believe anything is using it.
We need to pass an explicit CONFIG_BLKTAP1=n to qemu-xen-traditional
otherwise it defaults to y and doesn't build.
This patch does all the ground work, the tools/blktap directory will
be removed in the next (*huge*) patch.
Note that this has no impact on blktap2, which is what libxl supports.
blktap1 was only usable via xend which has already been removed.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Otherwise continue without it, which is preferable to the current
infinite hang.
Slightly tweak the grammar of a comment in the same function.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
As well as the existing common perf counters add a bunch of ARM
specifics, including the various trap types, vuart/vgic/vtimer
accesses and different types of interrupt.
Adjust the common code so that the columns line up again, not sure
when/where this went wrong.
This is mostly the set of stuff I happened to be interested in, it can
be made more (or less) fine grained as the need arises.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@linaro.org>
Some platform (such as the VFP Base AEMv8 model) has a memory mapped
timer. We don't want DOM0 use this timer rather than the generic ARM
timer. So blacklist it for all platforms.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When a domain is created on ARM, the grant table code initialized one
grant frame. With a basic load (i.e disk usage), Xen is quickly trying
to expand the number of frames:
(XEN) grant_table.c:1305:d2v0 Expanding dom (2) grant table from (1) to (2) frames.
(XEN) grant_table.c:1305:d2v0 Expanding dom (2) grant table from (2) to (3) frames.
(XEN) grant_table.c:311:d0v0 Increased maptrack size to 2 frames
(XEN) grant_table.c:311:d0v0 Increased maptrack size to 3 frames
The x86 code is initialied 4 frames (I didn't find the exact reason). I
think we could use the same default value.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The define INVALID_GFN is misplaced in arch-arm/grant_table.h and is
never used in neither in ARM nor in the common code.
Therefore we can safely remove it.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Jan Beulich
Andrew Cooper
Anthony PERARD
Wei Liu
Julien Grall
Jim Fehlig
Paul Durrant
Tim Deegan
Ian Campbell