Roger Pau Monne [Tue, 25 Jan 2022 15:19:24 +0000 (16:19 +0100)]
xen/pci: detect when BARs overlap RAM
One of the boxes where I was attempting to boot Xen in PVH dom0 mode
has quirky firmware, as it will handover with a device with memory
decoding enabled and a BAR of size 4K at address 0. Such BAR overlaps
with a RAM range on the e820.
This interacts badly with the dom0 PVH build, as BARs will be setup on
the p2m before RAM, so if there's a BAR positioned over a RAM region
it will trigger a domain crash when the dom0 builder attempts to
populate that region with a regular RAM page.
It's in general a very bad idea to have a BAR overlapping with a RAM
region, so add some sanity checks for devices that are added with
memory decoding enabled in order to assure that BARs are not placed on
top of memory regions. If overlaps are detected just disable the
memory decoding bit for the device and expect the hardware domain to
properly position the BAR.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
RFC because:
- Not sure the best way to implement is_iomem_range on Arm. BARs can
be quite big, so iterating over every possible page is not ideal.
- is_iomem_page cannot be used for this purpose on x86, because all
the low 1MB will return true due to belonging to dom_io.
- VF BARs are not checked. Should we also check them and disable VF
if overlaps in a followup patch?
Roger Pau Monne [Wed, 19 Jan 2022 16:32:30 +0000 (17:32 +0100)]
x86/vmsi: add support for extended destination ID in address field
Both QEMU/KVM and HyperV support using bits 11:5 from the MSI address
field in order to store the high part of the target APIC ID. This
allows expanding the maximum APID ID usable without interrupt
remapping support from 255 to 32768.
Note the interface used by QEMU for emulated devices (via the
XEN_DMOP_inject_msi hypercall) already passes both the address and
data fields into Xen for processing, so there's no need for any change
to QEMU there.
However for PCI passthrough devices QEMU uses the
XEN_DOMCTL_bind_pt_irq hypercall which does need an addition to the
gflags field in order to pass the high bits of the APIC destination
ID.
Introduce a new CPUID flag to signal the support for the feature. The
introduced flag covers both the support for extended ID for the
IO-APIC RTE and the MSI address registers. Such flag is currently only
exposed when the domain is using vPCI (ie: a PVH dom0).
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Roger Pau Monne [Wed, 19 Jan 2022 16:24:32 +0000 (17:24 +0100)]
xen/vioapic: add support for the extended destination ID field
Such field uses bits 55:48, but for the purposes the register will be
used use bits 55:49 instead. Bit 48 is used to signal an RTE entry is
in remappable format which is not supported by the vIO-APIC.
Use the extended destination ID to store the high bits from the
destination ID, thus expanding the size of the destination ID field to
15 bits, allowing an IO-APIC to target APIC IDs up to 32768.
Note this is already supported by QEMU/KVM and HyperV.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Julien Grall [Fri, 19 Nov 2021 11:27:47 +0000 (11:27 +0000)]
xen/grant-table: Only decrement the refcounter when grant is fully unmapped
The grant unmapping hypercall (GNTTABOP_unmap_grant_ref) is not a
simple revert of the changes done by the grant mapping hypercall
(GNTTABOP_map_grant_ref).
Instead, it is possible to partially (or even not) clear some flags.
This will leave the grant is mapped until a future call where all
the flags would be cleared.
XSA-380 introduced a refcounting that is meant to only be dropped
when the grant is fully unmapped. Unfortunately, unmap_common() will
decrement the refcount for every successful call.
A consequence is a domain would be able to underflow the refcount
and trigger a BUG().
Looking at the code, it is not clear to me why a domain would
want to partially clear some flags in the grant-table. But as
this is part of the ABI, it is better to not change the behavior
for now.
Fix it by checking if the maptrack handle has been released before
decrementing the refcounting.
Julien Grall [Tue, 14 Dec 2021 09:53:44 +0000 (09:53 +0000)]
xen/arm: p2m: Always clear the P2M entry when the mapping is removed
Commit 2148a125b73b ("xen/arm: Track page accessed between batch of
Set/Way operations") allowed an entry to be invalid from the CPU PoV
(lpae_is_valid()) but valid for Xen (p2m_is_valid()). This is useful
to track which page is accessed and only perform an action on them
(e.g. clean & invalidate the cache after a set/way instruction).
Unfortunately, __p2m_set_entry() is only zeroing the P2M entry when
lpae_is_valid() returns true. This means the entry will not be zeroed
if the entry was valid from Xen PoV but invalid from the CPU PoV for
tracking purpose.
As a consequence, this will allow a domain to continue to access the
page after it was removed.
Resolve the issue by always zeroing the entry if it the LPAE bit is
set or the entry is about to be removed.
Roger Pau Monne [Mon, 24 Jan 2022 16:13:12 +0000 (17:13 +0100)]
x86/pvh: fix population of the low 1MB for dom0
RMRRs are setup ahead of populating the p2m and hence the ASSERT when
populating the low 1MB needs to be relaxed when it finds an existing
entry: it's either RAM or a RMRR resulting from the IOMMU setup.
Rework the logic a bit and introduce a local mfn variable in order to
assert that if the gfn is populated and not RAM it is an identity map.
Fixes: 6b4f6a31ac ('x86/PVH: de-duplicate mappings for first Mb of Dom0 memory') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Add C-state table for the SnowRidge SoC which is found on Intel Jacobsville
platforms.
The following has been changed.
1. C1E latency changed from 10us to 15us. It was measured using the
open source "wult" tool (the "nic" method, 15us is the 99.99th
percentile).
2. C1E power break even changed from 20us to 25us, which may result
in less C1E residency in some workloads.
3. C6 latency changed from 50us to 130us. Measured the same way as C1E.
The C6 C-state is supported only by some SnowRidge revisions, so add a C-state
table commentary about this.
On SnowRidge, C6 support is enumerated via the usual mechanism: "mwait" leaf of
the "cpuid" instruction. The 'intel_idle' driver does check this leaf, so even
though C6 is present in the table, the driver will only use it if the CPU does
support it.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit: 9cf93f056f783f986c19f40d5304d1bcffa0fc0d] Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Mon, 24 Jan 2022 07:43:08 +0000 (08:43 +0100)]
x86/mwait-idle: switch to using bool
When the driver was first ported, we didn't have "bool" yet, so
conversion to bool_t / 0 / 1 was necessary. Undo that conversion, easing
ports of newer changes as well as tidying things up.
Requested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Mon, 24 Jan 2022 07:42:25 +0000 (08:42 +0100)]
x86/mwait-idle: stop exposing platform acronyms
This follows Linux commit de09cdd09fa1 ("intel_idle: stop exposing
platform acronyms in sysfs"), but their main justifications (sysfs
exposure and similarity with acpi-idle) don't apply to us. The field is
only used in a single printk() right now, but having the platform tags
there isn't useful either.
Requested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Mon, 24 Jan 2022 07:40:59 +0000 (08:40 +0100)]
x86/time: minor adjustments to init_pit()
For one, "using_pit" shouldn't be set ahead of the function's last
(for now: only) error path. Otherwise "clocksource=pit" on the command
line can lead to misbehavior when actually taking that error path.
And then make an implicit assumption explicit: CALIBRATE_FRAC cannot,
for example, simply be changed to 10. The way init_pit() works, the
upper bound on the calibration period is about 54ms.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 24 Jan 2022 07:38:55 +0000 (08:38 +0100)]
x86/APIC: no need for timer calibration when using TDT
The only global effect of calibrate_APIC_clock() is the setting of
"bus_scale"; the final __setup_APIC_LVTT(0) is (at best) redundant with
the immediately following setup_APIC_timer() invocation. Yet "bus_scale"
isn't used when using TDT. Avoid wasting 100ms for calibration in this
case.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Juergen Gross [Fri, 21 Jan 2022 13:12:19 +0000 (14:12 +0100)]
tools/xenstore: fix error handling of check_store()
check_store() has an incomplete error handling: it doesn't check
whether "root" allocation succeeded, and it is leaking the memory of
"root" in case create_hashtable() fails.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Roger Pau Monne [Thu, 20 Jan 2022 16:13:00 +0000 (17:13 +0100)]
xen/x86: import intel-family.h from Linux
Last commit to the file is:
7d697f0d5737 x86/cpu: Drop spurious underscore from RAPTOR_LAKE #define
This should help the readability of code that's currently open-coding
Intel model numbers.
No change introduced to existing code, it's expected that new code
could start using the defines. Changing existing users could cause
quite a lot of code churn.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Juergen Gross [Thu, 20 Jan 2022 06:59:47 +0000 (07:59 +0100)]
tools/xenstore: use talloc_asprintf_append() in do_control_help()
Instead of calculating the length of all help output and then
allocating the space for it, just use talloc_asprintf_append() to
expand the text as needed.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Andrew Cooper [Fri, 21 Jan 2022 10:19:00 +0000 (10:19 +0000)]
x86: Fix build with the get/set_reg() infrastructure
I clearly messed up concluding that the stubs were safe to drop.
The is_{pv,hvm}_domain() predicates are not symmetrical with both CONFIG_PV
and CONFIG_HVM. As a result logic of the form `if ( pv/hvm ) ... else ...`
will always have one side which can't be DCE'd.
While technically only the hvm stubs are needed, due to the use of the
is_pv_domain() predicate in guest_{rd,wr}msr(), sort out the pv stubs too to
avoid leaving a bear trap for future users.
Fixes: 88d3ff7ab15d ("x86/guest: Introduce {get,set}_reg() infrastructure") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Mon, 17 Jan 2022 18:40:50 +0000 (18:40 +0000)]
x86/hvm: Drop hvm_{get,set}_guest_bndcfgs() and use {get,set}_regs() instead
hvm_{get,set}_guest_bndcfgs() are thin wrappers around accessing MSR_BNDCFGS.
MPX was implemented on Skylake uarch CPUs and dropped in subsequent CPUs, and
is disabled by default in Xen VMs.
It would be nice to move all the logic into vmx_msr_{read,write}_intercept(),
but the common HVM migration code uses guest_{rd,wr}msr(). Therefore, use
{get,set}_regs() to reduce the quantity of "common" HVM code.
In lieu of having hvm_set_guest_bndcfgs() split out, use some #ifdef
CONFIG_HVM in guest_wrmsr(). In vmx_{get,set}_regs(), split the switch
statements into two depending on whether the require remote VMCS acquisition
or not.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 12 Jan 2022 15:47:27 +0000 (15:47 +0000)]
x86/spec-ctrl: Fix NMI race condition with VT-x MSR_SPEC_CTRL handling
The logic was based on a mistaken understanding of how NMI blocking on vmexit
works. NMIs are only blocked for EXIT_REASON_NMI, and not for general exits.
Therefore, an NMI can in general hit early in the vmx_asm_vmexit_handler path,
and the guest's value will be clobbered before it is saved.
Switch to using MSR load/save lists. This causes the guest value to be saved
atomically with respect to NMIs/MCEs/etc.
First, update vmx_cpuid_policy_changed() to configure the load/save lists at
the same time as configuring the intercepts. This function is always used in
remote context, so extend the vmx_vmcs_{enter,exit}() block to cover the whole
function, rather than having multiple remote acquisitions of the same VMCS.
Both of vmx_{add,del}_guest_msr() can fail. The -ESRCH delete case is fine,
but all others are fatal to the running of the VM, so handle them using
domain_crash() - this path is only used during domain construction anyway.
Second, update vmx_{get,set}_reg() to use the MSR load/save lists rather than
vcpu_msrs, and update the vcpu_msrs comment to describe the new state
location.
Finally, adjust the entry/exit asm.
Because the guest value is saved and loaded atomically, we do not need to
manually load the guest value, nor do we need to enable SCF_use_shadow. This
lets us remove the use of DO_SPEC_CTRL_EXIT_TO_GUEST. Additionally,
SPEC_CTRL_ENTRY_FROM_PV gets removed too, because on an early entry failure,
we're no longer in the guest MSR_SPEC_CTRL context needing to switch back to
Xen's context.
The only action remaining is to load Xen's MSR_SPEC_CTRL value on vmexit. We
could in principle use the host msr list, but is expected to complicated
future work. Delete DO_SPEC_CTRL_ENTRY_FROM_HVM entirely, and use a shorter
code sequence to simply reload Xen's setting from the top-of-stack block.
Adjust the comment at the top of spec_ctrl_asm.h in light of this bugfix.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 12 Jan 2022 16:36:29 +0000 (16:36 +0000)]
x86/spec-ctrl: Drop SPEC_CTRL_{ENTRY_FROM,EXIT_TO}_HVM
These were written before Spectre/Meltdown went public, and there was large
uncertainty in how the protections would evolve. As it turns out, they're
very specific to Intel hardware, and not very suitable for AMD.
Drop the macros, opencoding the relevant subset of functionality, and leaving
grep-fodder to locate the logic. No change at all for VT-x.
For AMD, the only relevant piece of functionality is DO_OVERWRITE_RSB,
although we will soon be adding (different) logic to handle MSR_SPEC_CTRL.
This has a marginal improvement of removing an unconditional pile of long-nops
from the vmentry/exit path.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Various registers have per-guest-type or per-vendor locations or access
requirements. To support their use from common code, provide accessors which
allow for per-guest-type behaviour.
For now, just infrastructure handling default cases and expectations.
Subsequent patches will start handling registers using this infrastructure.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 13 Jan 2022 18:37:13 +0000 (18:37 +0000)]
x86/hvm: Drop .is_singlestep_supported() callback
There is absolutely no need for a function pointer call here.
Drop the hook, introduce a singlestep_supported boolean, and configure it in
start_vmx() like all other optional functionality.
No functional change, but rather more efficient logic.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>
Roger Pau Monné [Wed, 19 Jan 2022 12:51:26 +0000 (13:51 +0100)]
libs/guest: move cpu policy related prototypes to xenguest.h
Do this before adding any more stuff to xg_cpuid_x86.c.
The placement in xenctrl.h is wrong, as they are implemented by the
xenguest library. Note that xg_cpuid_x86.c needs to include
xg_private.h, and in turn also fix xg_private.h to include
xc_bitops.h. The bitops definition of BITS_PER_LONG needs to be
changed to not be an expression, so that xxhash.h can use it in a
preprocessor if directive.
As a result also modify xen-cpuid to include xenguest.h.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Chen Yu [Wed, 19 Jan 2022 12:50:43 +0000 (13:50 +0100)]
x86/mwait-idle: Adjust the SKX C6 parameters if PC6 is disabled
Because cpuidle assumes worst-case C-state parameters, PC6 parameters
are used for describing C6, which is worst-case for requesting CC6.
When PC6 is enabled, this is appropriate. But if PC6 is disabled
in the BIOS, the exit latency and target residency should be adjusted
accordingly.
Exit latency:
Previously the C6 exit latency was measured as the PC6 exit latency.
With PC6 disabled, the C6 exit latency should be the one of CC6.
Target residency:
With PC6 disabled, the idle duration within [CC6, PC6) would make the
idle governor choose C1E over C6. This would cause low energy-efficiency.
We should lower the bar to request C6 when PC6 is disabled.
To fill this gap, check if PC6 is disabled in the BIOS in the
MSR_PKG_CST_CONFIG_CONTROL(0xe2) register. If so, use the CC6 exit latency
for C6 and set target_residency to 3 times of the new exit latency. [This
is consistent with how intel_idle driver uses _CST to calculate the
target_residency.] As a result, the OS would be more likely to choose C6
over C1E when PC6 is disabled, which is reasonable, because if C6 is
enabled, it implies that the user cares about energy, so choosing C6 more
frequently makes sense.
The new CC6 exit latency of 92us was measured with wult[1] on SKX via NIC
wakeup as the 99.99th percentile. Also CLX and CPX both have the same CPU
model number as SkX, but their CC6 exit latencies are similar to the SKX
one, 96us and 89us respectively, so reuse the SKX value for them.
There is a concern that it might be better to use a more generic approach
instead of optimizing every platform. However, if the required code
complexity and different PC6 bit interpretation on different platforms
are taken into account, tuning the code per platform seems to be an
acceptable tradeoff.
Link: https://intel.github.io/wult/ Suggested-by: Len Brown <len.brown@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
[ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit: 64233338499126c5c31e07165735ab5441c7e45a]
Alongside the dropping of "const" from skx_cstates[] add __read_mostly,
and extend that to other similar non-const tables.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Artem Bityutskiy [Wed, 19 Jan 2022 12:45:11 +0000 (13:45 +0100)]
x86/mwait-idle: update ICX C6 data
Change IceLake Xeon C6 latency from 128 us to 170 us. The latency
was measured with the "wult" tool and corresponds to the 99.99th
percentile when measuring with the "nic" method. Note, the 128 us
figure correspond to the median latency, but in intel_idle we use
the "worst case" latency figure instead.
C6 target residency was increased from 384 us to 600 us, which may
result in less C6 residency in some workloads. This value was tested
and compared to values 384, and 1000. Value 600 is a reasonable
tradeoff between power and performance.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit: d484b8bfc6fa71a088e4ac85d9ce11aa0385867e] Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
x86/mwait-idle: mention assumption that WBINVD is not needed
Intel SDM does not explicitly say that entering a C-state via MWAIT will
implicitly flush CPU caches as appropriate for that C-state. However,
documentation for individual Intel CPU generations does mention this
behavior.
Since intel_idle binds to any Intel CPU with MWAIT, list this assumption
of MWAIT behavior.
In passing, reword opening comment to make it clear that the driver can
load on any old and future Intel CPU with MWAIT.
Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit: 8bb2e2a887afdf8a39e68fa0dccf82a168aae655]
Dropped "reword opending comment" part - this doesn't apply to our code:
First thing mwait_idle_probe() does is call x86_match_cpu(); we do not
have a 2nd such call looking for just MWAIT (in order to the use _CST
data directly, which we can't get our hands at _CST at this point yet).
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Juergen Gross [Sun, 16 Jan 2022 08:23:46 +0000 (09:23 +0100)]
tools/libs/ctrl: remove file related handling
There is no special file handling related to libxenctrl in Mini-OS
any longer, so the close hook can be removed.
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Juergen Gross [Sun, 16 Jan 2022 08:23:45 +0000 (09:23 +0100)]
tools/libs/gnttab: decouple more from mini-os
libgnttab is using implementation details of Mini-OS. Change that by
letting libgnttab use the new alloc_file_type() and get_file_from_fd()
functions and the generic dev pointer of struct file from Mini-OS.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Juergen Gross [Sun, 16 Jan 2022 08:23:44 +0000 (09:23 +0100)]
tools/libs/evtchn: decouple more from mini-os
Mini-OS and libevtchn are using implementation details of each other.
Change that by letting libevtchn use the new alloc_file_type() and
get_file_from_fd() function and the generic dev pointer of struct file
from Mini-OS.
By using private struct declarations Mini-OS will be able to drop the
libevtchn specific definitions of struct evtchn_port_info and
evtchn_port_list in future. While at it use bool for "pending" and
"bound".
Switch to use xce as function parameter instead of fd where possible.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Mon, 17 Jan 2022 08:45:04 +0000 (09:45 +0100)]
x86/HVM: convert remaining hvm_funcs hook invocations to alt-call
The aim being to have as few indirect calls as possible (see [1]),
whereas during initial conversion performance was the main aspect and
hence rarely used hooks didn't get converted. Apparently one use of
get_interrupt_shadow() was missed at the time.
While doing this, drop NULL checks ahead of CPU management and .nhvm_*()
calls when the hook is always present. Also convert the
.nhvm_vcpu_reset() call to alternative_vcall(), as the return value is
unused and the caller has currently no way of propagating it.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>
[1] https://lists.xen.org/archives/html/xen-devel/2021-11/msg01822.html
Jan Beulich [Fri, 14 Jan 2022 10:03:03 +0000 (11:03 +0100)]
build: adjust include/xen/compile.h generation
Prior to 19427e439e01 ("build: generate "include/xen/compile.h" with
if_changed") running "make install-xen" as root would not have printed
the banner under normal circumstances. Its printing would instead have
indicated that something was wrong (or during a normal build the lack
of printing would do so).
Further aforementioned change had another undesirable effect, which I
didn't notice during review: Originally compile.h would have been
re-generated (and final binaries re-linked) when its dependencies were
updated after an earlier build. This is no longer the case now, which
means that if some other file also was updated, then the re-build done
during "make install-xen" would happen with a stale compile.h (as its
updating is suppressed in this case).
Restore the earlier behavior for both aspects.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
This is a fastpath on virtual vmentry/exit, and forcing guest_pat to be
spilled to the stack is bad. Performing the shift in a register is far more
efficient.
Drop the (IMO useless) log message. MSR_PAT only gets altered on boot, and a
bad value will be entirely evident in the ensuing #GP backtrace.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 30 Nov 2021 17:05:09 +0000 (17:05 +0000)]
x86/hvm: Rework nested hap functions to reduce parameters
Most functions in this call chain have 8 parameters, meaning that the final
two booleans are spilled to the stack for calls.
First, delete nestedhap_walk_L1_p2m and introduce nhvm_hap_walk_L1_p2m() as a
thin wrapper around hvm_funcs, just like all the other nhvm_*() hooks. This
involves including xen/mm.h as the forward declaration of struct npfec is no
longer enough.
Next, replace the triple of booleans with struct npfec, which contains the
same information in the bottom 3 bits.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jason Andryuk [Thu, 13 Jan 2022 13:33:16 +0000 (14:33 +0100)]
libxl/PCI: Fix PV hotplug & stubdom coldplug
commit 0fdb48ffe7a1 "libxl: Make sure devices added by pci-attach are
reflected in the config" broken PCI hotplug (xl pci-attach) for PV
domains when it moved libxl__create_pci_backend() later in the function.
This also broke HVM + stubdom PCI passthrough coldplug. For that, the
PCI devices are hotplugged to a running PV stubdom, and then the QEMU
QMP device_add commands are made to QEMU inside the stubdom.
A running PV domain calls libxl__wait_for_backend(). With the current
placement of libxl__create_pci_backend(), the path does not exist and
the call immediately fails:
libxl: error: libxl_device.c:1388:libxl__wait_for_backend: Backend /local/domain/0/backend/pci/43/0 does not exist
libxl: error: libxl_pci.c:1764:device_pci_add_done: Domain 42:libxl__device_pci_add failed for PCI device 0:2:0.0 (rc -3)
libxl: error: libxl_create.c:1857:domcreate_attach_devices: Domain 42:unable to add pci devices
The wait is only relevant when:
1) The domain is PV
2) The domain is running
3) The backend is already present
This is because:
1) xen-pcifront is only used for PV. It does not load for HVM domains
where QEMU is used.
2) If the domain is not running (starting), then the frontend state will
be Initialising. xen-pciback waits for the frontend to transition to
at Initialised before attempting to connect. So a wait for a
non-running domain is not applicable as the backend will not
transition to Connected.
3) For presence, num_devs is already used to determine if the backend
needs to be created. Re-use num_devs to determine if the backend
wait is necessary. The wait is necessary to avoid racing with
another PCI attachment reconfiguring the front/back or changing to
some other state like closing. If we are creating the backend, then
we don't have to worry about the state since it is being created.
Fixes: 0fdb48ffe7a1 ("libxl: Make sure devices added by pci-attach are
reflected in the config")
Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Thu, 13 Jan 2022 13:31:52 +0000 (14:31 +0100)]
x86/time: improve TSC / CPU freq calibration accuracy
While the problem report was for extreme errors, even smaller ones would
better be avoided: The calculated period to run calibration loops over
can (and usually will) be shorter than the actual time elapsed between
first and last platform timer and TSC reads. Adjust values returned from
the init functions accordingly.
On a Skylake system I've tested this on accuracy (using HPET) went from
detecting in some cases more than 220kHz too high a value to about
±2kHz. On other systems (or on this system, but with PMTMR) the original
error range was much smaller, with less (in some cases only very little)
improvement.
Reported-by: James Dingwall <james-xen@dingwall.me.uk> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Thu, 13 Jan 2022 13:30:18 +0000 (14:30 +0100)]
x86/time: use relative counts in calibration loops
Looping until reaching/exceeding a certain value is error prone: If the
target value is close enough to the wrapping point, the loop may not
terminate at all. Switch to using delta values, which then allows to
fold the two loops each into just one.
Fixes: 93340297802b ("x86/time: calibrate TSC against platform timer") 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>
Daniel P. Smith [Wed, 12 Jan 2022 07:55:20 +0000 (08:55 +0100)]
MAINTAINERS: requesting to be TXT reviewer
I would like to submit myself, Daniel P. Smith, as a reviewer of TXT support in
Xen.
Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Juergen Gross [Wed, 12 Jan 2022 07:54:59 +0000 (08:54 +0100)]
tools/debugger: fix make distclean
"make distclean" will complain that "-c" is no supported flag for make.
Fix that by using "-C".
The error has been present for a long time, but it was uncovered only
recently.
Fixes: 2400a9a365c5619 ("tools/debugger: Allow make to recurse into debugger/") Fixes: f9c9b127753e9ed ("tools: fix make distclean") Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Tested-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Wed, 12 Jan 2022 07:54:20 +0000 (08:54 +0100)]
x86/paging: replace most mfn_valid() in log-dirty handling
Top level table and intermediate table entries get explicitly set to
INVALID_MFN when un-allocated. There's therefore no need to use the more
expensive mfn_valid() when checking for that sentinel.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Wed, 12 Jan 2022 07:53:05 +0000 (08:53 +0100)]
x86/paging: tidy paging_mfn_is_dirty()
The function returning a boolean indicator, make it return bool. Also
constify its struct domain parameter, albeit requiring to also adjust
mm_locked_by_me(). Furthermore the function is used by shadow code only.
Since mm_locked_by_me() needs touching anyway, also switch its return
type to bool.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Juergen Gross [Tue, 11 Jan 2022 10:43:48 +0000 (11:43 +0100)]
SUPPORT.md: limit support statement for Linux and Windows frontends
Change the support state of Linux and Windows pv frontends from
"supported" to "supported with caveats" in order to reflect that the
frontends can probably be harmed by their respective backends.
Some of the Linux frontends have been hardened already.
This is XSA-376
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Tue, 11 Jan 2022 10:42:49 +0000 (11:42 +0100)]
x86/viridian: EOI MSR should always happen in affected vCPU context
The HV_X64_MSR_EOI wrmsr should always happen with the target vCPU
as current, as there's no support for EOI'ing interrupts on a remote
vCPU.
While there also turn the unconditional assert at the top of the
function into an error on non-debug builds.
No functional change intended.
Requested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 6 Jan 2022 15:12:39 +0000 (16:12 +0100)]
x86/altp2m: p2m_altp2m_get_or_propagate() should honor present page order
Prior to XSA-304 the only caller merely happened to not use any further
the order value that it passes into the function. Already then this was
a latent issue: The function really should, in the "get" case, hand back
the order the underlying mapping actually uses (or actually the smaller
of the two), such that (going forward) there wouldn't be any action on
unrelated mappings (in particular ones which did already diverge from
the host P2M).
Similarly in the "propagate" case only the smaller of the two orders
should actually get used for creating the new entry, again to avoid
altering mappings which did already diverge from the host P2M.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tamas K Lengyel <tamas@tklengyel.com>
Jan Beulich [Thu, 6 Jan 2022 15:12:15 +0000 (16:12 +0100)]
tools/xen-detect: avoid possible pitfall with cpuid()
The 64-bit form forces %ecx to 0 while the 32-bit one so far didn't - it
only ended up that way when "pv_context" is zero. While presently no
leaf queried by callers has separate subleaves, let's avoid chancing it.
While there
- replace references to operands by number,
- relax constraints where possible,
- limit PUSH/POP to just the registers not also used as input,
all where applicable also for the 64-bit variant.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Andrew Cooper [Tue, 4 Jan 2022 14:11:55 +0000 (14:11 +0000)]
x86/spec-ctrl: Fix default calculation of opt_srb_lock
Since this logic was introduced, opt_tsx has become more complicated and
shouldn't be compared to 0 directly. While there are no buggy logic paths,
the correct expression is !(opt_tsx & 1) but the rtm_disabled boolean is
easier and clearer to use.
Fixes: 8fe24090d940 ("x86/cpuid: Rework HLE and RTM handling") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 23 Dec 2021 16:10:15 +0000 (16:10 +0000)]
tools/libxc: Drop copy-in in xc_physinfo()
The first thing XEN_SYSCTL_physinfo does is zero op->u.physinfo.
Do not copy-in. It's pointless, and most callers don't initialise their
xc_physinfo_t buffer to begin with. Remove the redundant zeroing from the
remaining callers.
Spotted by Coverity.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Wei Chen <Wei.Chen@arm.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Tue, 4 Jan 2022 09:21:12 +0000 (10:21 +0100)]
xenperf: omit meaningless trailing zeroes from output
There's no point producing a long chain of zeroes when the previously
calculated total value was zero. To guard against mistakenly skipping
non-zero individual fields, widen "sum" to "unsigned long long".
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Tue, 4 Jan 2022 09:20:15 +0000 (10:20 +0100)]
libxc: avoid clobbering errno in xc_domain_pod_target()
do_memory_op() supplies return value and has "errno" set the usual way.
Don't overwrite "errno" with 1 (aka EPERM on at least Linux). There's
also no reason to overwrite "err".
Jan Beulich [Tue, 4 Jan 2022 09:19:32 +0000 (10:19 +0100)]
VT-d: shorten vtd_flush_{context,iotlb}_reg()
Their calculations of the value to write to the respective command
register can be partly folded, resulting in almost 100 bytes less code
for these two relatively short functions.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Tue, 4 Jan 2022 09:18:18 +0000 (10:18 +0100)]
VT-d: use DMA_TLB_IVA_ADDR()
Let's use the macro in the one place it's supposed to be used, and in
favor of then unnecessary manipulations of the address in
iommu_flush_iotlb_psi(): All leaf functions then already deal correctly
with the supplied address.
There also has never been a need to require (i.e. assert for) the
passing in of 4k-aligned addresses - it'll always be the order-sized
range containing the address which gets flushed.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Tue, 4 Jan 2022 09:16:48 +0000 (10:16 +0100)]
xenperf: name "newer" hypercalls
This table must not have got updated in quite a while; tmem_op for
example has managed to not only appear since then, but also disappear
again (adding a name for it nevertheless, to make more obvious that
something strange is going on if the slot would ever have a non-zero
value).
Also resolve arch_0 and arch_1 to more meaningful names on x86.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 4 Jan 2022 09:16:04 +0000 (10:16 +0100)]
VT-d: avoid allocating domid_{bit,}map[] when possible
When an IOMMU implements the full 16 bits worth of DID in context
entries, there's no point going through a memory base translation table.
For IOMMUs not using Caching Mode we can simply use the domain IDs
verbatim, while for Caching Mode we need to avoid DID 0.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Tue, 4 Jan 2022 09:13:06 +0000 (10:13 +0100)]
x86/EPT: squash meaningless TLB flush
ept_free_entry() gets called after a flush was already issued, if one is
necessary in the first place. That behavior is similar to NPT, which
also doesn't have any further flush in p2m_free_entry(). (Furthermore,
the function being recursive, in case of recursiveness way too many
flushes would have been issued.)
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Jan Beulich [Tue, 21 Dec 2021 09:42:02 +0000 (10:42 +0100)]
mm: introduce INVALID_{G,M}FN_RAW
This allows properly tying together INVALID_{G,M}FN and
INVALID_{G,M}FN_INITIALIZER as well as using the actual values in
compile time constant expressions (or even preprocessor directives).
Since INVALID_PFN is unused, and with x86'es paging_mark_pfn_dirty()
being the only user of pfn_t it also doesn't seem likely that new uses
would appear, remove that one at this same occasion.
Jan Beulich [Tue, 21 Dec 2021 09:38:18 +0000 (10:38 +0100)]
x86/perfc: conditionalize HVM and shadow counters
There's no point including them when the respective functionality isn't
enabled in the build. Note that this covers only larger groups; more
fine grained exclusion may want to be done later on.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Fri, 8 Oct 2021 12:40:17 +0000 (13:40 +0100)]
x86/traps: Clean up diagnostics
do{_unhandled,}_trap() should use fatal_trap() rather than opencoding part of
it. This lets the remote stack trace logic work in more fatal error
conditions.
With do_trap() converted, there is only one single user of trapstr()
remaining. Tweak the formatting in pv_inject_event(), and remove trapstr()
entirely. Rename vec_name() to vector_name() now that it is exported.
Take the opportunity of vector_name() being exported to improve the
diagnostics in stub_selftest().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 7 Oct 2021 13:04:03 +0000 (14:04 +0100)]
x86/traps: Drop exception_table[] and use if/else dispatching
There is also a lot of redundancy in the table. 8 vectors head to do_trap(),
3 are handled in the IST logic, and that only leaves 7 others not heading to
the do_reserved_trap() catch-all. This also removes the fragility that any
accidental NULL entry in the table becomes a ticking timebomb.
Function pointers are expensive under retpoline, and different vectors have
wildly different frequences. Drop the indirect call, and use an if/else chain
instead, which is a code layout technique used by profile-guided optimsiation.
Using Xen's own perfcounter infrastructure, we see the following frequences of
vectors measured from boot until I can SSH into dom0 and collect the stats:
vec | CFL-R | Milan | Notes
----+---------+---------+
NMI | 345 | 3768 | Watchdog. Milan has many more CPUs.
----+---------+---------+
#PF | 1233234 | 2006441 |
#GP | 90054 | 96193 |
#UD | 848 | 851 |
#NM | 0 | 132 | Per-vendor lazy vs eager FPU policy.
#DB | 67 | 67 | No clue, but it's something in userspace.
Bloat-o-meter (after some manual insertion of ELF metadata) reports:
add/remove: 0/1 grow/shrink: 2/0 up/down: 102/-256 (-154)
Function old new delta
handle_exception_saved 148 226 +78
handle_ist_exception 453 477 +24
exception_table 256 - -256
showing that the if/else chains are less than half the size that
exception_table[] was in the first place.
As part of this change, make two other minor changes. do_reserved_trap() is
renamed to do_unhandled_trap() because it is the catchall, and already covers
things that aren't reserved any more (#VE/#VC/#HV/#SX).
Furthermore, don't forward #TS to guests. #TS is specifically for errors
relating to the Task State Segment, which is a Xen-owned structure, not a
guest-owned structure. Even in the 32bit days, we never let guests register
their own Task State Segments.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Thu, 28 Oct 2021 03:07:02 +0000 (04:07 +0100)]
xen/domain: Remove function pointers from domain pause helpers
Function pointer calls are expensive (especially with Spectre v2 protections),
and all these do are select between the sync and nosync helpers. Pass a
boolean instead, and use direct calls everywhere.
Pause/unpause operations on behalf of dom0 are not fastpaths, so avoid
exposing the __domain_pause_by_systemcontroller() internal.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Michal Orzel [Fri, 17 Dec 2021 07:21:59 +0000 (08:21 +0100)]
xen/arm64: Zero the top 32 bits of gp registers on entry...
to hypervisor when switching from AArch32 state.
According to section D1.20.2 of Arm Arm(DDI 0487A.j):
"If the general-purpose register was accessible from AArch32 state the
upper 32 bits either become zero, or hold the value that the same
architectural register held before any AArch32 execution.
The choice between these two options is IMPLEMENTATION DEFINED"
Currently Xen does not ensure that the top 32 bits are zeroed and this
needs to be fixed. The reason why is that there are places in Xen
where we assume that top 32bits are zero for AArch32 guests.
If they are not, this can lead to misinterpretation of Xen regarding
what the guest requested. For example hypercalls returning an error
encoded in a signed long like do_sched_op, do_hmv_op, do_memory_op
would return -ENOSYS if the command passed as the first argument was
clobbered.
Create a macro clobber_gp_top_halves to clobber top 32 bits of gp
registers when hyp == 0 (guest mode) and compat == 1 (AArch32 mode).
Add a compile time check to ensure that save_x0_x1 == 1 if
compat == 1.
Signed-off-by: Michal Orzel <michal.orzel@arm.com>
[julieng: Tweak the comment in clobber_gp_top_halves] Acked-by: Julien Grall <jgrall@amazon.com>
Jan Beulich [Fri, 17 Dec 2021 07:56:34 +0000 (08:56 +0100)]
hvmloader: tidy pci_mem_{start,end}
For one at least pci_mem_start has to be precisely 32 bits wide, so use
uint32_t for both. Otherwise expressions like "pci_mem_start <<= 1"
won't have the intended effect (in their context).
Further since its introduction pci_mem_end was never written to. Mark it
const to make this explicit.
Finally drop PCI_MEM_END: It is used just once and needlessly
disconnected from the other constant (RESERVED_MEMBASE) it needs to
match. Use RESERVED_MEMBASE as initializer of pci_mem_end instead.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
While its description is correct from an abstract or real hardware pov,
the range is special inside HVM guests. The range being UC in particular
gets in the way of OVMF, which places itself at [FFE00000,FFFFFFFF].
While this is benign to epte_get_entry_emt() as long as the IOMMU isn't
enabled for a guest, it becomes a very noticable problem otherwise: It
takes about half a minute for OVMF to decompress itself into its
designated address range.
And even beyond OVMF there's no reason to have e.g. the ACPI memory
range marked UC.
Fixes: c22bd567ce22 ("hvmloader: PA range 0xfc000000-0xffffffff should be UC") 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>
Luca Fancellu [Mon, 13 Dec 2021 11:48:54 +0000 (11:48 +0000)]
arm/efi: Handle Xen bootargs from both xen.cfg and DT
Currently the Xen UEFI stub can accept Xen boot arguments from
the Xen configuration file using the "options=" keyword, but also
directly from the device tree specifying xen,xen-bootargs
property.
When the configuration file is used, device tree boot arguments
are ignored and overwritten even if the keyword "options=" is
not used.
This patch handle this case, so if the Xen configuration file is not
specifying boot arguments, the device tree boot arguments will be
used, if they are present.
Luca Fancellu [Thu, 16 Dec 2021 22:43:19 +0000 (14:43 -0800)]
xen/arm: increase memory banks number define value
Currently the maximum number of memory banks (NR_MEM_BANKS define)
is fixed to 128, but on some new platforms that have a large amount
of memory, this value is not enough and prevents Xen from booting.
Andrew Cooper [Tue, 14 Dec 2021 20:04:17 +0000 (20:04 +0000)]
x86/cpuid: Advertise SERIALIZE by default to guests
I've played with SERIALIZE, TSXLDTRK, MOVDIRI and MOVDIR64 on real hardware,
and they all seem fine, including emulation support.
SERIALIZE exists specifically to have a userspace usable serialising operation
without other side effects. (The only other two choices are CPUID which is a
VMExit under virt and clobbers 4 registers, and IRET-to-self which very slow
and consumes content from the stack.)
TSXLDTRK is a niche TSX feature, and TSX itself is niche outside of demos of
speculative sidechannels. Leave the feature opt-in until a usecase is found,
in an effort to preempt the multiple person years of effort it has taken to
mop up TSX issues impacting every processor line.
MOVDIRI and MOVDIR64 are harder to judge. They're architectural building
blocks towards ENQCMD{,S} without obvious usecases on their own. They're of
no use to domains without PCI devices, so leave them opt-in for now.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 14 Dec 2021 16:53:36 +0000 (16:53 +0000)]
x86/cpuid: Introduce dom0-cpuid command line option
Specifically, this lets the user opt in to non-default features.
Collect all dom0 settings together in dom0_{en,dis}able_feat[], and apply it
to dom0's policy when other tweaks are being made.
As recalculate_cpuid_policy() is an expensive action, and dom0-cpuid= is
likely to only be used by the x86 maintainers for development purposes, forgo
the recalculation in the general case.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 15 Dec 2021 16:30:25 +0000 (16:30 +0000)]
x86/cpuid: Factor common parsing out of parse_xen_cpuid()
dom0-cpuid= is going to want to reuse the common parsing loop, so factor it
out into parse_cpuid().
Irritatingly, despite being static const, the features[] array gets duplicated
each time parse_cpuid() is inlined. As it is a large (and ever growing with
new CPU features) datastructure, move it to being file scope so all inlines
use the same single object.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Wed, 15 Dec 2021 15:36:59 +0000 (15:36 +0000)]
x86/cpuid: Split dom0 handling out of init_domain_cpuid_policy()
To implement dom0-cpuid= support, the special cases would need extending.
However there is already a problem with late hwdom where the special cases
override toolstack settings, which is unintended and poor behaviour.
Introduce a new init_dom0_cpuid_policy() for the purpose, moving the ITSC and
ARCH_CAPS logic. The is_hardware_domain() can be dropped, and for now there
is no need to rerun recalculate_cpuid_policy(); this is a relatively expensive
operation, and will become more-so over time.
Rearrange the logic in create_dom0() to make room for a call to
init_dom0_cpuid_policy(). The AMX plans for having variable sized XSAVE
states require that modifications to the policy happen before vCPUs are
created.
Additionally, factor out domid into a variable so we can be slightly more
correct in the case of a failure, and also print the error from
domain_create(). This will at least help distinguish -EINVAL from -ENOMEM.
No practical change in behaviour.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Anthony PERARD [Mon, 6 Dec 2021 17:02:33 +0000 (17:02 +0000)]
tools/Rules.mk: Cleanup %.pc rules
PKG_CONFIG_VARS isn't set anymore, so is dead logic.
For "local" pkg-config file, we only have one headers directory now,
"tools/include", so there is no need to specify it twice. So remove
$(CFLAGS_xeninclude) from "Cflags:".
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
With "xentoolcore_internal.h" been in LIBHEADER, it was installed. But
its dependency "_xentoolcore_list.h" wasn't installed so the header
couldn't be used anyway.
This patch also mean that the rule "headers.chk" doesn't check it
anymore as well.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Juergen Gross <jgross@suse.com>
Anthony PERARD [Mon, 6 Dec 2021 17:02:17 +0000 (17:02 +0000)]
tools/xcutils: rework Makefile
Use TARGETS to collect targets to build
Remove "build" target.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
[Clean up $(RM)] Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD [Mon, 6 Dec 2021 17:02:15 +0000 (17:02 +0000)]
tools/misc: rework Makefile
Add missing "xen-detect" rule. It only works without it because we
still have make's built-ins rules and variables, but fix this to not
have to rely on them.
Rename $(TARGETS_BUILD) to $(TARGETS).
Remove the unused "build" target.
Also, they are no more "build-only" targets, remove the extra code.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Anthony PERARD [Mon, 6 Dec 2021 17:02:04 +0000 (17:02 +0000)]
tools/include/xen-foreign: avoid to rely on default .SUFFIXES
When a rule isn't a pattern rule, and thus don't have a %, the
value of the automatic variable stem $* depends on .SUFFIXES. GNU make
manual explain that it is better to avoid this "bizarre" behavior
which exist for compatibility.
Use $(basename ) instead. So we can one day avoid make's build-in
rules and variables.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
projects / people / royger / xen.git / log