With the exception of the custom IBT job, copy all Debian 12 jobs making
Debian 13 versions, then trim the Debian 12 ranconfig jobs.
Update the test jobs using Debian 12 to use 13.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Marek noticed that some builds were failing with:
+ cd dist/install
+ find
+ cpio -R 0:0 -o -H newc
./automation/scripts/build: line 111: cpio: command not found
+ gzip
but succeeding overall, and producing a zero length xen-tools.cpio.gz as an
artefact.
In fact, it's all of:
archlinux:current
debian:12-x86_32
fedora:41
opensuse:tumbleweed
ubuntu (all versions)
Add cpio into all of these containers, including opensuse leap for good
measure, and use pipefail in the build script.
Fixes: 4611ae6fb8 ("CI: save toolstack artifact as cpio.gz")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Randconfig with GCC-14 (Debian Trixie) found:
In file included from arch/x86/x86_emulate/x86_emulate.c:11,
from arch/x86/x86_emulate.c:27:
arch/x86/x86_emulate/x86_emulate.c: In function 'x86_emulate':
arch/x86/x86_emulate/private.h:482:8: error: Too many conditions (found 826); giving up coverage [-Werror=coverage-too-many-conditions]
482 | ({ if ( (p) ) { \
| ^
arch/x86/x86_emulate/x86_emulate.c:1283:5: note: in expansion of macro 'generate_exception_if'
1283 | generate_exception_if((mode_vif() &&
| ^~~~~~~~~~~~~~~~~~~~~
which is a consequence of having a new enough compiler to allow
CONFIG_CONDITION_COVERAGE in to the mix.
In the short term make warning non-fatal, but this will need fixing
properly in due course.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
The OVMF package in Debian Trixie has _4M suffixes on the files. Have
scripts/include/xtf-x86-64-efi check for this before falling back to no
suffix.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
cpio needs to be in Tools (general) now that it's used by the general build
script. Merge the rest of the test phase jobs into one group, to avoid being
overly fine-grain.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Everything works fine with Debian 13. Provide two new build jobs (for a total
of 6), and update the test jobs.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Everything works fine with Debian 13. Provide two new build jobs, and update
both the randconfig the test jobs.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
We have a mix of root and non-root containers, and are trying to become
rootless. This can cause the local CPIO fragements to end up being user:user
in the test environment.
Nothing seems to go wrong so far, but it's a trap waiting to happen.
Make everything consistently root for the initrds, irrespective of the
rootness of the container the test is running in.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
... instead of having them split across multiple.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Drop unused or stale lines.
* While it's necessary to have .git and .hg in each others ignore files if
using multiple SCMs (as we did for a while), they should not be in their
own. The mercurial files were dropped in commit ba5bae659d ("Drop
remains of prior SCMs") (2023).
* The ignore for LibVNCServer* was added by commit a090ca495e ("VNC pasword
authentication support for the paravirt framebuffer server.") (2006) but
without justification or any obvious reason.
* The ignore for tools/misc/lowmemd was added in commit c812282081 ("Low
mem virq incremental adjustments") (2012), but xen-lowmemd (from the same
author) already existed and was ignored properly.
* tools/libs/guest/xc_* were added in commit af6c78d9dc ("tools: move
libxenctrl below tools/libs") for bisectibility, but should have been
dropped in the following change, commit e3dd624e48 ("tools/libxc: move
libxenguest to tools/libs/guest").
* tools/debugger/xenitp/ was dropped in commit e567964a54 ("tools: drop
ia64 support") (2012).
* tools/debugger/gdb/ was dropped in commit
baa1aae9cf ("tools/debugger/gdb: Remove gdb") (2010).
* tools/misc/cpuperf/ was dropped in commit ae95fdf65a ("[TOOLS] Remove the
'cpuperf' misc tool.") (2006).
* tools/misc/xc_shadow was dropped in commit 7133144e3a ("Remove xc_shadow
tool") (2007).
* tools/misc/xen_cpuperf was dropped in commit 60eba9b0d2 ("Delete some
unused tools") (2004).
* tools/misc/xen-tmem-list-parse was dropped in commit c588c002cc ("tools:
remove tmem code and commands") (2018).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
One aspect of the old ffs() infrastructure was the use of TZCNT without a
CPUID check. Given no obvious justification, I dropped it during the cleanup.
It turns out there is a good reason, on all but the most recent AMD CPUs.
Reinstate the use of "blind" TZCNT when safe to do so. This happens to be
preferentially in loops where a repeated saving of 5-6 uops becomes far more
relevant than a one-off scenario. Leave an explanation of why.
It is not safe to perform this transformation for BSR and LZCNT, because they
count from opposite ends of the input operand. Furthermore, this incorrect
transform was not caught by the selftests.
Extend the selftests with test_for_each_set_bit_reverse() as that exercises
the "x known non-zero" optimsiation path in x86's helpers. Adjust the
existing test_for_each_set_bit() to intentionally use an asymmetric input bit
pattern, otherwise "counting from the wrong end" bugs continue to slip by.
No functional change.
Fixes: 989e5f08d3 ("x86/bitops: Improve arch_ffs() in the general case")
Fixes: 5ed26fc076 ("xen/bitops: Implement ffsl() in common logic")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It is not obvious at first glance, but this is dead logic.
On Intel, xAPIC (which is what modern_apic() is really checking for) predates
64bit support, while the Family 0xf check on AMD is the K8 processor.
Simply drop the logic, rather than trying to adjust vendor/family logic.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of
get_physical_broadcast()") to Xen. Thomas Gleixner notes:
There is no point for this function. The only case where this is used is
when there is no XAPIC available, which means the broadcast address is 0xF.
In Linux, users of get_physical_broadcast() have already been hidden behind
CONFIG_X86_32 suggesting we can drop all of this, but that's a task for some
other time.
In Xen as with Linux, setup_ioapic_ids_from_mpc() and io_apic_get_unique_id()
only apply to pre-xAPIC cases, so can use a broadcast ID of 0xf. The only
other user is __print_IO_APIC() for diagnostics, which can simply drop the
check.
No functional change.
Link: https://lore.kernel.org/r/20240212154639.057209154@linutronix.de
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Jan reports the following exception when using the cycle debugging:
Feature IBRSB, seen [IBRSB, STIBP, INTEL_PSFD, EIBRS, IPRED_CTRL, RRSBA_CTRL, RRSBA, BHI_CTRL], to_process [SSBD]
Traceback (most recent call last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 594, in <module>
sys.exit(main())
^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 588, in main
crunch_numbers(state)
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 366, in crunch_numbers
(state.names[feat], repl(seen), repl(to_process)))
^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in repl
return "[" + ", ".join((state.names[x] for x in l)) + "]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in <genexpr>
return "[" + ", ".join((state.names[x] for x in l)) + "]"
~~~~~~~~~~~^^^
KeyError: 534
make[2]: *** [/local/xen.git/xen/include/xen/lib/x86/Makefile:9: cpuid-autogen.h] Error 1
This is caused by commit ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature
names") being rather lazy and marking dependenices on unknown features.
Introduce a helper to pick the known features in a range, and use it for
ARCH_CAPS.
Additionally, remove trailing whitespace and an unnecessary line continuation
from the debug print.
Reported-by: Jan Beulich <jbeulich@suse.com>
Fixes: ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature names")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
FRED and IDT differ by a Supervisor Token on the base of the shstk. This
means that the value they load into MSR_PL0_SSP differs by 8.
s3_resume() in particular has logic which is otherwise invariant of FRED mode,
and must not clobber a FRED MSR_PL0_SSP with an IDT one.
This also simplifies the AP path too.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Under FRED, SETSSBSY is disallowed, and we want to be setting up FRED prior to
setting up shadow stacks. Luckily, RSTORSSP will also work in this case.
This involves a new type of shadow stack token, the Restore Token, which is
distinguished from the Supervisor Token by pointing to the adjacent slot on
the shadow stack rather than pointing at itself.
In the short term, this logic still needs to load MSR_PL0_SSP.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
percpu_early_traps_init() will shortly be setting CR4.FRED. This requires
that cpu_info->cr4 is already set up, and that the enablement of CET doesn't
truncate X86_CR4_FRED back out because of using 32bit logic.
For __high_start(), defer re-loading XEN_MINIMAL_CR4 until after %rsp is set
up and we can store the result in the cr4 field too.
For s3_resume(), explicitly re-load XEN_MINIMAL_CR4. Later when loading all
features, use the mmu_cr4_features variable which is how the rest of Xen
performs this operation.
No functional change, yet.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... disabled by default. There is a lot of work before FRED can be enabled by
default.
One part of FRED, the LKGS (Load Kernel GS) instruction, is enumerated
separately but expected to be mandatory as FRED disallows the SWAPGS
instruction. Normally, we'd have to check both CPUID bits, but Xen does not
use GS like most other software, and can manage without LKGS.
FRED formally removes the use of Ring1 and Ring2, meaning we cannot run 32bit
PV guests. As already done with CET, disable PV32 if using FRED, except in
shim mode where FRED is disabled by default.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The FRED on-stack format is larger than the IDT format, but is by and large
compatible. FRED reuses space above cs and ss for extra metadata, some of
which is purely informational, and some of which causes additional effects in
ERET{U,S}.
Follow Linux's choice of naming for fred_{c,s}s structures, to make it very
clear at the point of use that it's dependent on FRED.
There is also the event data field and reserved fields, but we cannot include
these in struct cpu_user_regs without reintroducing OoB structure accesses in
the non-FRED case. See commit 6065a05adf ("x86/traps: 'Fix' safety of
read_registers() in #DF path"). for more details.
Instead, use a new struct fred_info and position it suitably in struct
cpu_info. This boundary will be loaded into MSR_FRED_RSP_SL0, and must be
64-byte aligned.
This does add 16 bytes back into struct cpu_info, undoing the saving we made
by dropping the vm86 data segment selectors.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Of note, CR4.FRED is bit 32 and cannot enabled outside of 64bit mode.
Most supported toolchains don't understand the FRED instructions yet.
Nevertheless, ERETU and ERETS are easy to wrap (they encoded as REPZ/REPNE
CLAC), while LKGS turns out not to be needed by Xen.
We will need some alternatives based on FRED, so add a synthetic
X86_FEATURE_XEN_FRED.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
There's no family check gating intel_init_ppin(), making it incorrect to use
on non Fam6 CPUs. Switch to using VFM.
Emerald Rapids is the final CPU to have PPIN but lack the the architectural
enumeration, so include it too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
GCC 5.1 is the minimum supported toolchain version now. Drop the workaround
for the PIC hard register in earlier versions.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... on capable toolchains.
This avoids needing to hold rc in a register across the RDMSR, and in most
cases removes direct testing and branching based on rc, as the fault label can
be rearranged to directly land on the out-of-line block.
There is a subtle difference in behaviour. The old behaviour would, on fault,
still produce 0's and write to val.
The new behaviour only writes val on success, and write_msr() is the only
place where this matters. Move temp out of switch() scope and initialise it
to 0.
While it is possible to retain the old behaviour, it's not great to do so
because the compiler cannot optimise out the dead store when it's not to a
local function variable, and Xen has a lot of msr infrastructure which passes
a val pointer through the call-tree. We have compilers with ASM_GOTO_OUTPUT
in CI, and they do notice.
Resolves: https://gitlab.com/xen-project/xen/-/work_items/217
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... in preparation to be able to use asm goto.
Notably this mean that the value parameter must be taken by pointer rather
than by value.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We're about to turn the rdmsr() macro into a real function, at which point
Eclair complains that we're now shadowing an identifer.
Rename rdmsr to is_read.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Now that content has been split out, minimise the header files as msr.h is
included by many translation units. A few more TUs were pulling dependencies
in transitively, so fix them up.
Give asm/time.h an SPDX tag, update it's guards, and drop the unused rdpmc().
If we do re-gain uses, the helper will want a proper API.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
With asm/tsc.h split out, asm/time.h shouldn't be including asm/msr.h, but it
turns out that an outrageous number of files (even some headers) are pulling
their dependentices transitively through asm/time.h -> asm/msr.h
Most are asm/msr{,-index}.h, but in some cases it's printk(), va_args, and
even PRIxxx macros.
Give asm/time.h an SPDX tag, update it's guards, and strip trailing
whitespace.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Now there is a local header, asm/cpu-user-regs.h is a far better place for
these to live.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The TSC functionality is only related to MSRs by write_tsc(), and this really
does not want to be available as widely as is currently is.
asm/time.h shouldn't be including asm/msr.h, but this turns out to be
sufficiently tangled that I've chosen to break it out into it's own patch.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It is a large and complex API, but only a handful of translation units need
access.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
struct vcpu_msrs has a very different purpose to everything else in msr.h
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This was almost certainly copy&paste from x86. ARM does not us these nor
selects HAS_EX_TABLE, so drop the sections and their boundary markers.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Julien Grall <jgrall@amazon.com>
These can become static now the two traps.c have been merged.
No fucntional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It's now just the double fault handler and various state dumping functions.
Swap u64 for uint64_t, and fix a few other minor style issues.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... along with the supporting functions. Switch to Xen coding style, and make
static as there are no external callers.
Rename to legacy_syscall_init() as a more accurate name.
Swap wrmsr{,l}() for wrmsrns(). No serialisation is needed at this point.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Switch it to Xen coding style and fix MISRA violations (ul -> UL). Make it
static as there are no external caller now.
Since commit a35816b5ca ("x86/traps: Introduce early_traps_init() and
simplify setup"), load_system_tables() is called later on the BSP, so the
SYS_STATE_early_boot check can be dropped from the safety BUG_ON().
Move the BUILD_BUG_ON() into build_assertions(), and introduce an
endof_field() helper to make the expression clearer.
Swap wrmsrl(MSR_ISST, ...) for wrmsrns(). No serialisation is needed at this
point.
Drop the comment about Clang 3.5. It's no longer a supported toolchain, and
while the comment is true, the code should have been written with a local
pointer anyway.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
As things stand, we set up AP/S3 exception handling marginally after the
fragile activity of setting up shadow stacks. Shadow stack setup is going to
get more complicated under FRED.
Introduce percpu_early_traps_init() and call it ahead of setting up shadow
stacks. To start with, call load_system_tables() which is sufficient to set
up full exception handling.
In order to handle exceptions, current and the speculation controls needs to
work. cpu_smpboot_alloc() already constructs some of the AP's top-of-stack
block, so have it set up a little more. Zero the whole structure to subsume
other misc setup.
This gets us complete exception coverage of setting up shadow stacks, rather
than dying with a triple fault.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
We're going to want to reuse it for a remote stack shortly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The result of this calculation will always be identical, even across context
switch in x86. Tell the compiler.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
... to abstract away updating the refereces to the old BSP stack.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
We're going to want to introduce a percpu version shortly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This was added erroneously by me.
Hardware task switching does demand a TSS of at least 0x67 bytes, but that's
not relevant in 64bit, and not relevant for Xen since commit
5d1181a5ea ("xen: Remove x86_32 build target.") in 2012.
We already load a 0-length TSS in early_traps_init() demonstrating that it's
possible.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
After some experimentation, using .a/.b makes far better logic than using the
named fields, as both Clang and GCC spill idte to the stack when named fields
are used.
GCC seems to do something very daft for the addr1 field. It takes addr,
shifts it by 32, then ANDs with 0xffff0000000000000UL, which requires
manifesting a MOVABS.
Clang follows the C, whereby it ANDs with $imm32, then shifts, avoiding the
MOVABS entirely.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In hindsight, having the wrapper name not be the instruction mnemonic was a
poor choice. Also, PKRS turns out to be quite rare in wanting a split value.
Switch to using a single 64bit value ahead of introducing new users.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
AMD call this whole structure the ISST, which is a better association with IST
than the long form (which becomes ambiguous when abbreviated).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The data segment registers are part of the on-stack IRET frame when
interrupting Virtual 8086 mode, but this ceased being relevant for Xen in
commit 5d1181a5ea ("xen: Remove x86_32 build target.") in 2012.
With all other cleanup in place, delete the fields so we can introduce FRED
support which uses this space for different data.
Everywhere which used the es field as an offset in cpu_user_regs needs
adjusting. However, they'll change again for FRED, so no cleanup is performed
at this juncture.
This also undoes the OoB Read workaround in show_registers(), which can now
switch back to being simple structure copy.
No functional change, but a lot of rearranging of stack and struct layout
under the hood.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In order to support FRED, we're going to have to remove the {ds..gs} fields
from struct cpu_user_regs, meaning that it is going to have to become a
different type to the structure embedded in vcpu_guest_context_u.
struct cpu_user_regs is a name used in common Xen code (i.e. needs to stay
using this name), so renaming the public struct to be guest_user_regs in Xen's
view only.
Introduce a brand hew cpu-user-regs.h, currently containing a duplicate
structure.
Notably, this removes the need to include pubic/xen.h in ~every translation
unit in Xen (via current.h), and highlights one case where the emulator was
picking up cpu_user_regs transitively.
Include comments describing how hardware interacts with this structure under
IDT delivery, as it's quite magic to start with. FRED is going make things
more complicated.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
In order to support FRED, we're going to have to remove the {ds..gs} fields
from struct cpu_user_regs. This will impact v->arch.user_regs.
These fields are unused for HVM guests, but for PV hold the selector values
when the vCPU is scheduled out.
Introduce new fields for the selectors in struct pv_vcpu, and update:
* {save,load}_segments(), context switching
* arch_{set,set}_info_guest(), hypercalls
* vcpu_show_registers(), diagnostics
* dom0_construct(), PV dom0
to use the new storage. This removes the final user of read_sregs() so drop
it too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In order to support FRED, we're going to have to remove the {ds..gs} fields
from struct cpu_user_regs, meaning that it is going to have to become a
different type to the structure embedded in vcpu_guest_context_u.
In both arch_{get,set}_info_guest(), expand the memcpy()/XLAT_cpu_user_regs()
to copy the fields individually. This will allow us to eventually make them
different types.
This does cause some minor changes in behaviour for the hypercalls.
It is specifically not the case that a toolstack could set_info(); get_info();
and get an identical bit pattern back. Amongst other things, the
architectural sticky bits in registers are applied during setting.
Previously, XLAT_cpu_user_regs() omitted the _pad fields in the compat case
whereas the non-compat case included them owing to the single memcpy().
Omit the _pad fields in the non-compat case too; for all but the oldest of
CPUs, the segment selectors are zero-extended by hardware when pushed onto the
stack, so non-zero values here get lost naturally. Furthermore, FRED reuses
the space above cs and ss for extra state, and a PV guest for now at least
must not be able to write the control state.
Omit the error_code and entry_vector fields too. They're already identified
as private fields in the public API, and are stale outside of Xen's
interrupt/exception/syscall handler. They're also a very minor information
leak of which event caused the last deschedule of a vCPU.
Finally, omit saved_upcall_mask. Xen doesn't consume this, and only produces
it in {compat_,}create_bounce_frame(), based on the vcpu_info shared state and
settings about the event being injected. Similar to error_code/entry_vector,
it is stale outside of the guest's event handler.
No change that toolstacks or guests are expected to notice or care about.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The API is unergonomic to use, and leads to poor code generation because of
unnecessary forcing of data to the stack.
Rename build_id_p to xen_build_id, and build_id_len to xen_build_id_len, make
them __ro_after_init, and export the variables directly.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Ross Lagerwall <Ross.lagerwall@citrix.com>
Both callsites call them as a pair, and more generally, anyone wanting the
changeset wants the buildid too.
This involves rearranging console_init_preirq() to ensure xen_build_init() is
ahead of print_version().
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Having multiple values wrapped onto as few lines as practical is good for
space efficiency, but causes complex collisions for hypercall backports and
local policy changes. Reformat to use one value per line.
No functional change, only whitespace changes.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Most indentation is with tabs, but a few spaces have slipped in. Switch them
back to tabs.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
Hypercalls are not free; cache colouring is an experimental feature, and
ignoring an -EOPNOTSUPP is bad form.
Now that Xen has been fixed to initialise colouring information correctly for
domains, xc_domain_set_llc_colors() only needs calling for domains with
explicit configuration.
Rearrange the logic to avoid the hypercall in the general case, leaving a
comment explaining why it is performed so early.
Fixes: 748bd725fb ("tools: add support for cache coloring configuration")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Right now, domains start with no colouring information and depend on a
XEN_DOMCTL_set_llc_colors(nr=0) hypercall in order to get default colours.
This in turn forces the toolstack to make a hypercall for all VMs even those
without colouring configured, and to ignore errors if Xen doesn't have
colouring active.
Introduce domain_llc_coloring_init(), replacing domain_set_default_colors(),
and call it during the trivial initialisation in domain_create(). Leave two
comments explaining the positioning.
The -EEXISTs condition in domain_set_llc_colors() needs adjusting as a
consequence, but that's easy enough to keep working as before.
Fixes: 6cdea3444e ("xen/arm: add Dom0 cache coloring support")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
domain_destroy() is the wrong position to be freeing colouring information,
which is only used for allocations.
The comment in context identifies how domain_destroy() can be called multiple
times on the same domain, leading to a double free of d->llc_colors as it's
the wrong side of the atomic_cmpxchg() to be made safe.
Furthermore, by freeing d->llc_colors but leaving d->num_llc_colors nonzero,
alloc_color_heap_page() can in principle use after free.
Make domain_llc_coloring_free() idempotent, zeroing d->num_llc_colors and
NULL-ing d->llc_colors after freeing, and call it from domain_teardown().
Fixes: 6985aa5e0c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Using:
xfree(__va(__pa(d->llc_colors)));
is an extraordinarily expensive way of writing:
xfree((void *)d->llc_colours);
Combined with the comment indicating that this was intention, the patch should
have been rejected outright.
Correct the type of d->llc_colours by removing the bogus const on it, and
remove the cast when freeing it.
No functional change.
Fixes: 6985aa5e0c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
This snapshot is Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
the *_FAM6_ CPU #defines"), now that Xen has switched off the old constant
names.
Leave a comment identifying the exact revision Xen is using.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Switch to the new fields and constants.
In mwait_idle_probe(), exit early for non-Intel CPUs. intel_idle_ids[] is a
large (and ever increasing) table and it's not reasonable to scan it for other
vendors, nor is it ideal to be emitting a somewhat-ambiguous error message.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
helper to match a specific stepping, and use it to rework deadline_match[].
Currently, the table is scanned on all systems, even those without the
TSC_DEADLINE feature. Introduce another early exit for that case, which also
removes the need to encode every row in the table with TSC_DEADLINE.
Notably this removes the overloading of driver_data possibly being a function
pointer, and removes the latent bug where the target functions are missing
ENDBR instructions owing to the lack of the cf_check attribute.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Architecturally, stepping is a 4-bit field, so a uint16_t suffices for a
bitmap of steppings.
In order to keep the size of struct x86_cpu_id the same, shrink the vendor and
family fields; there's no need for them to be uint16_t in Xen, and this
matches the size of the fields in cpuinfo_x86.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Xen's use of struct x86_cpu_id is a bit different to Linux's, so we can
simplify the loop termination condition. Leave a comment explaining Xen's
assumptions.
Switch to Xen style, as we've properly deviated from Linux, and switch to the
new vendor/family/model names.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This replaces raw model numbers (and comments in some cases) with names. For
probe_mwait_errata(), merge the comments with the table to make it easier to
see which erratum is which, and drop a stray "Problem" in LNL030.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
mwait-idle's ICPU() is the most convenient place to get started. Introduce
X86_MATCH_CPU() and X86_MATCH_VFM() following their Linux counterparts.
This involves match-cpu.h including more headers, which in turn allows us to
drop a few.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Only 5 files use struct x86_cpu_id, so it should not be in processor.h. This
is in preparation to extend it with VFM support.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In intel.c, drop asm/mwait.h and asm/uaccess.h, neither of which are used.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
NEHALEM_EX is affected by the erratum too.
Change the comment to be the full erratum text, not an interpretation of it.
Fixes: 95807bcae4 ("C6 state with EOI issue fix for some Intel processors")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In udelay(), use cpu_relax() directly which, for better or worse, is the
common way to refer to the PAUSE instruction.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This snapshot is prior to Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
the *_FAM6_ CPU #defines") at the end of their conversion phase.
In addition to non-FAM6 infixed names, defines are added for the Pentium Pro,
ArrowLake U, and reintroduced the PHI defines which were incorrectly deleted
in the past.
In cpufeature.h, provide VFM_* macros to transform constants to/from the
cpuinfo_x86 representation.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Intel have run out of model space in Family 6 and will start using Family 19
starting with Diamond Rapids. Xen, like Linux, has model checking logic which
will malfunction owing to bad assumptions about the family field.
Reorder the family, vendor and model fields so they can be accessed together
as a single vfm field.
As we're cleaning up the logic, take the opportunity to introduce better
names, dropping the x86 prefix.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
TSA affects AMD Fam19h CPUs (Zen3 and 4 microarchitectures).
Three new CPUID bits have been defined. Two (TSA_SQ_NO and TSA_L1_NO)
indicate that the system is unaffected, and must be synthesised by Xen on
unaffected parts to date.
A third new bit indicates that VERW now has a flushing side effect. Xen
must synthesise this bit on affected systems based on microcode version.
As with other VERW-based flushing features, VERW_CLEAR needs OR-ing across
a resource pool, and guests which have seen it can safely migrate in.
This is part of XSA-471 / CVE-2024-36350 / CVE-2024-36357.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In order to mitigate TSA, Xen will need to issue VERW before going idle.
On AMD CPUs, the VERW scrubbing side effects cancel an active MONITOR, causing
the MWAIT to exit without entering an idle state. Therefore the VERW must be
ahead of MONITOR.
Split spec_ctrl_enter_idle() in two and allow the VERW aspect to be handled
separately. While adjusting, update a stale comment concerning MSBDS; more
issues have been mitigated using VERW since it was written.
By moving VERW earlier, it is ahead of the determination of whether to go
idle. We can't move the check on softirq_pending (for correctness reasons),
but we can duplicate it earlier as a best effort attempt to skip the
speculative overhead.
This is part of XSA-471 / CVE-2024-36350 / CVE-2024-36357.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
AMD are releasing microcode for TSA, so extend the known-provenance list with
their hashes. These were produced before the remediation of the microcode
signature issues (the entrysign vulnerability), so can be OS-loaded on
out-of-date firmware.
Include an off-by-default check for the sorted-ness of patch_digests[]. It's
not worth running generally under SELF_TESTS, but is useful when editing the
digest list.
This is part of XSA-471 / CVE-2024-36350 / CVE-2024-36357.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Turn the if()s into switch()es, as we're going to need AMD sections.
Move the RTM adjustments into the Intel section, where they ought to live.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The check of this_softirq_pending must be performed with irqs disabled, but
this property was broken by an attempt to optimise entry/exit latency.
Commit c227233ad64c in Linux (which we copied into Xen) was fixed up by
edc8fc01f608 in Linux, which we have so far missed.
Going to sleep without waking on interrupts is nonsensical outside of
play_dead(), so overload this to select between two possible MWAITs, the
second using the STI shadow to cover MWAIT for exactly the same reason as we
do in safe_halt().
Fixes: b17e0ec72e ("x86/mwait-idle: enable interrupts before C1 on Xeons")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
In order elide IPIs, we must be able to identify whether a target CPU is in
MWAIT at the point it is woken up. i.e. the store to wake it up must also
identify the state.
Create a new in_mwait variable beside __softirq_pending, so we can use a
CMPXCHG to set the softirq while also observing the status safely. Implement
an x86 version of arch_pend_softirq() which does this.
In mwait_idle_with_hints(), advertise in_mwait, with an explanation of
precisely what it means. X86_BUG_MONITOR can be accounted for simply by not
advertising in_mwait.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
x86 is the only architecture wanting an optimisation here, but the
test_and_set_bit() is a store into the monitored line (i.e. will wake up the
target) and, prior to the removal of the broken IPI-elision algorithm, was
racy, causing unnecessary IPIs to be sent.
To do this in a race-free way, the store to the monited line needs to also
sample the status of the target in one atomic action. Implement a new arch
helper with different semantics; to make the softirq pending and decide about
IPIs together. For now, implement the default helper. It will be overridden
by x86 in a subsequent change.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
With the recent simplifications, it becomes obvious that smp_mb() isn't the
right barrier. Strictly speaking, MONITOR is ordered as a load, but smp_rmb()
isn't correct either, as this only pertains to local ordering. All we need is
a compiler barrier().
Merge the barier() into the monitor() itself, along with an explantion.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
cpuidle_wakeup_mwait() is a TOCTOU race. The cpumask_and() sampling
cpuidle_mwait_flags can take a arbitrary period of time, and there's no
guarantee that the target CPUs are still in MWAIT when writing into
mwait_wakeup(cpu).
The consequence of the race is that we'll fail to IPI certain targets. Also,
there's no guarantee that mwait_idle_with_hints() will raise a TIMER_SOFTIRQ
on it's way out.
The fundamental bug is that the "in_mwait" variable needs to be in the
monitored line, and not in a separate cpuidle_mwait_flags variable, in order
to do this in a race-free way.
Arranging to fix this while keeping the old implementation is prohibitive, so
strip the current one out in order to implement the new one cleanly. In the
interim, this causes IPIs to be used unconditionally which is safe albeit
suboptimal.
Fixes: 3d521e933e ("cpuidle: mwait on softirq_pending & remove wakeup ipis")
Fixes: 1adb34ea84 ("CPUIDLE: re-implement mwait wakeup process")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper