The most recent xenoprof change was 300ef0cb4f ("x86: Add Xenoprofile
support for AMD Family16h") in 2013, despite there being 42 changes worth of
other cleanup/rearranging since then.
Oprofile themselves dropped Xen support in commit 0c142c3a096d ("Remove
opcontrol and the GUI and processor models dependent on it") in 2014, as part
of releasing version 1.0 and switching over to using operf based on the Linux
perf_event subsystem. Linux's version of this patch was merged in commit
24880bef417f ("Merge tag 'oprofile-removal-5.12'") in 2021.
Drop xenoprof and all supporting infrastructure, including the hypercall, the
XSM hook and flask vectors which lose their only caller, and even shrinks
struct domain by one pointer which wasn't properly excluded in
!CONFIG_XENOPROF builds.
Retain the public xenoprof.h header as it is ABI, but note that the
functionality is removed.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
xen/drivers/passthrough/arm/ipmmu-vmsa.c contains a git:// URL in a block
comment. This is also not an example of commented out code, so shouldn't be
considered a R3.1 violation.
Extend the regex to include git://, and swap hyperlink for URL in the
associated documentation to be more precise.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
When Cscope-ing through Xen, one occasionally finds themselves in
xen-hypercall-defs.h and needing to find the originating file.
This is substantially magic, and even reading the Makefile that produces
xen-hypercall-defs.h is of little help if you're not aware of of the %.i : %.c
pattern rule, and that the header is generated from a .c file in practice.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Having an #ifdef CONFIG_X86 section in a common library is rude.
Furthermore, for x86 the main logic is 6 bytes, meaning it's ripe for
inlining. Create an x86-specific asm/muldiv.h implementing arch_muldiv64().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
muldiv64() has 7 users across all architectures, and is limited to time
handling functions. Therefore, move it's declaration out of lib.h into a
dedicated header.
Rename the library function to generic_muldiv64(), as x86 is going to provide
an arch_muldiv64() in a subsequent change.
Explain what the function does, including the limitations; x86's version will
suffer a divide error rather than truncate the result to 64 bits.
Annotate it with attr_const, not that this allows the optimiser to improve any
of Xen's current users. Add one selftest to check the internal precision,
putting it in bitops.c for want of any better place to put it.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
WORDS_BIGENDIAN is a QEMU-ism. In the very dim and distant past, we had a
fork of QEMU living in xen.git which wired WORDS_BIGENDIAN in the userspace
part of the build, but nothing ever wired it up in the hypervisor build.
Fixes: 86d5da49a6 ("[HVM] Support multiple HVM time device models coming soon.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
set_guest_*_trapbounce() are only called from assembly so gain asmlinkage to
identify them.
xen_msr_s_cet_value() is called by assembly and C, so asmlinkage isn't
appropriate. Make the declaration unconditional, which silences the
complaint.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
These are mostly name mismatches, but a couple have type alias mismatches too.
For shadow_put_top_level() and is_patch(), the declaration name is the better
choice so change the name in the function.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The automatically generated hypercall dispatch logic looks like:
case __HYPERVISOR_update_descriptor: \
ret = do_update_descriptor((uint64_t)(a1), (seg_desc_t)(a2)); \
break; \
but seg_desc_t is a union and Eclair considers this to be a violation of MISRA
Rule 1.1. There's also a Rule 8.3 violation for the parameter name mismatch.
Instead of playing games trying to change seg_desc_t to be a struct, or to
alter the AWK generator to know that seg_desc_t is magic and needs braces
rather than brackets, just switch the type to be a plain uint64_t.
The size is fixed by the x86 architecture, so it is never going to change.
This even lets us simplify compat_update_descriptor() a little.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA doesn't like mixing hexadecimal escape sequences with ASCII text. Use
the same workaround as in commit cd50483537 ("xen: address MISRA C:2012 Rule
4.1").
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... and split the x86 group away from the common group.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
It's not acceptable to hide this from the caller; the effect of doing so is to
break an atomicity expectation.
Only the caller can know what the appropriate safety action is in the case
that the claim hypercall isn't available. Ignoring it might be the right
thing to do, but xc_domain_claim_pages() cannot make this decision on behalf
of all callers.
Fixes: fc67e9dc0c ("xc: use XENMEM_claim_pages hypercall during guest creation.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
XENMEM_claim_pages can be issued on a domain in the later stages of
domain_kill(). In that case, the claimed memory is leaked, as there's no way
to subsequently release the claim.
Claims are intended for use during domain construction; to reserve sufficient
RAM to construct the domain fully. There's no legitimate reason to be calling
it on a dying domain.
Fixes: 65c9792df6 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
While doing so, make some style fixes to comments/etc.
This removes the include/asm/hvm/svm/ subdirectory.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
While doing so, move the ns_gif field to beside ns_hap_enabled to remove 7
padding bytes, and make some style fixes to comments/etc.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
In order to reduce the header tangle around xen/sched.h, we need to split
types away from other declarations.
Introduce a new hvm/svm-types.h to do this, including it from hvm/domain.h and
hvm/vcpu.h, and dropping all other inclusions of svm/vmcb.h and
svm/nestedhvm.h
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The single user of svm_intercept_msr() outside of the main svm logic is in
vpmu_amd.c. Currently the declaration is picked up transitively through
xen/sched.h, so include asm/hvm/svm.h explicitly.
Sort the headers while doing so.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... in preparation to remove the svm/ directory entirely.
intr.c doesn't need to include svm.h at all.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
MISRA Rule 5.5 objects to a macro aliasing a function, which is what
pirq_cleanup_check() does. The macro was originally intended to ensure the
condition 'if (!pirq->evtchn)' is always checked before invoking the function,
avoiding errors across call sites.
There are only a handful of users, so expand it inline to be plain regular
C. Doing this shows one path now needing braces, and one path in
'evtchn_bind_pirq()' where the expanded form simplifies back to no delta, as
it follows an unconditional clear of 'info->evtchn'.
While this complies with MISRA, it shifts the responsibility to developers to
check 'if (!pirq->evtchn)' at call sites.
No functional changes.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
All Eclair scanning is for safety purposes, and the *-safety jobs are AMD's
configuration specifically, and other configurations will likely be different.
Rename them to *-amd.
Give the un-suffixed job an *-allcode suffix to make it clearer that they're
looking at all code.
Give the un-suffixed scheduled jobs an *-allrules suffix.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
With the wider testing, some more violations have been spotted. This
addresses violations of Rule 20.7 which requires macro parameters to be
bracketed.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
With the wider testing, some more violations have been spotted. This
addresses violations of Rule 16.3 which requires all case statements to be
terminated with a break or other unconditional control flow change.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
With the wider testing, some more violations have been spotted. This
addresses violations of Rule 8.2 (parameters must be named).
livepatch_op() has a further problem. The other declaration (the stub for
!LIVEPATCH builds) has a parameter named op, but the definition has the
parameter named livepatch. Rename it to op which is more concise and better
in line with it's type name.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
With the wider testing, some more violations have been spotted. This
addresses violations of Rule 7.2 (suffixes required) and Rule 7.3 (L must be
uppercase).
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
This one comment didn't match the #ifdef symbol, and escaped conversion.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Michal Orzel <michal.orzel@amd.com>
Alpine Linux, when using --enable-systemd to get the init files, fails with:
tools/include/xen-sd-notify.h:69:3: error: call to undeclared library
function 'memcpy' with type 'void *(void *, const void *, unsigned long)';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
69 | memcpy(socket_addr.sun.sun_path, socket_path, path_length);
| ^
This will be down to using musl rather than glibc. Include the appropriate
header.
Fixes: 78510f3a15 ("tools: Import stand-alone sd_notify() implementation from systemd")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
svmdebug.h now only contains the declaration for svm_sync_vmcb(), despite the
logic being local to svm.c. Move the declaration into the local svm.h
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Everything here is really VMCB functionality, so merge it into vmcb.c. Move
the declarations from the global svmdebug.h to the local vmcb.h.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The rest of Xen has no buisness knowing this structure, and it is currently
included via xen/sched.h into most code. Create a new private svm/vmcb.h.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The hv_compat_vstart variable is hidden behind CONFIG_PV32 but lives in
arch_domain. Moving it into pv_domain is an obvious improvement.
Its value however is less obvious, and is a mess.
In !PV32 builds, it's uniformly treated as 0, but in PV32 builds it's ~0U (HVM
guests), __HYPERVISOR_COMPAT_VIRT_START (PV guests), or custom (PV32 dom0).
This seems to work because users are guarded behind is_pv32_{domain,vcpu}().
Simplify things by leaving it as 0 in PV32 builds for most domains,
initialising it in only in switch_compat() when a domain becomes 32bit PV.
dom0_construct() adjusts the value after calling switch_compat().
Suggested-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Prior to commit 02e78311cd ("x86/domctl: Make XEN_DOMCTL_set_address_size
singleshot", Xen 4.9, 2016), it was possible for domains to switch to being
compat, and back again. Since then however, becoming compat is a singleton
action that can't be undone.
From the context it's clear to see the is_pv_32bit_domain() check is
redundant, and from the singleton nature and being the only place setting
physaddr_bitsize, there's no need to check it for being 0.
No functional change.
Co-developed-by: Grygorii Strashko <grygorii_strashko@epam.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Grygorii Strashko <grygorii_strashko@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
The variable, when compiled in, is never 0, but because the writes into it are
hidden behind the HYPERVISOR_COMPAT_VIRT_START() macro, it has a very good
impression of being 0.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Grygorii Strashko <grygorii_strashko@epam.com>
Linux jumps to the target image rather than calling it. Switch to using JMP,
and drop the trailing UD2s.
Linux does have a mode, named CONFIG_KEXEC_JUMP, where the target image can be
returned from, but that involves extra metadata and setting up a stack within
the target image which Xen doesn't support at the moment.
No functional change.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It's soon going to be needed in a second location.
Right now it's misleading saying that nothing else would be cleared. It's
missing the more important point that SYSCALLs are treated like all other
interrupts and exceptions, and undergo normal flags handling there.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Right now we have two IRET instructions that can fault for guest reasons, and
the pre exception table gives handle_exception as the fixup for both.
Instead, we can have compat_restore_all_guest() use restore_all_guest()'s IRET
which gives us just a single position to handle specially.
In exception_with_ints_disabled(), remove search_pre_exception_table() and use
a simpler check. Explain how the recovery works, because this isn't the first
time I've had to reverse engineer it for my own understanding.
The reference to iret_to_guest highlights that any checking here is specific
to CONFIG_PV, so exclude it in !PV builds.
Later in exception_with_ints_disabled(), it suffices to load %ecx rather than
%rcx, and remove a stray semi-colon from the REP MOVSQ.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2
manually.
Rename do_page_fault() to handle_PF(), and update it to take cr2, still named
addr for consistency.
Introduce a new handle_PF_IDT() which reads %cr2 and conditionally re-enables
interrupts.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
FRED provides PENDING_DBG in the the stack frame, avoiding the need to read
%dr6 manually.
Rename do_debug() to handle_DB(), and update it to take a dbg field using
positive polarity.
Introduce a new handle_DB_IDT() which reads %dr6.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is really a rearrangement to make adding FRED support easier.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-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. As we still need Supervisor Tokens in IDT mode, we
need mode-specific logic to establish SSP.
In FRED mode, write a Restore Token, RSTORSSP it, and discard the resulting
Previous-SSP token.
No change outside of FRED mode.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
It turns out that using the higher level helpers adjacent like this leads to
terrible code generation. Due to -fno-strict-aliasing, the store into state
invalidates the read_cr4() address calculation (which is really cpu_info->cr4
under the hood), meaning that it can't be hoisted.
As a result we get "locate the top of stack block, get cr4, and see if
FSGSBASE is set" repeated 3 times, and an unreasonable number of basic blocks.
Hoist the calculation manually, which results in two basic blocks.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
... and rdmsr() while here.
Most of these accesses are in fastpaths and do not need serialising behaviour,
but the write side is serialising on all Intel hardware as well as older AMD
hardware.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Right now they're inline in {read,write}_gs_shadow(), but we're going to need
to use these elsewhere to support FRED.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Hans reports that Xen no longer builds on Debian unstable/sid:
Assembler messages:
{standard input}:474: Error: unknown or missing system register name at operand 1 -- `msr TEECR32_EL1,x0'
{standard input}:480: Error: unknown or missing system register name at operand 1 -- `msr TEEHBR32_EL1,x0'
{standard input}:488: Error: unknown or missing system register name at operand 2 -- `mrs x0,TEECR32_EL1'
{standard input}:494: Error: unknown or missing system register name at operand 2 -- `mrs x0,TEEHBR32_EL1'
make[5]: *** [Rules.mk:249: arch/arm/domain.o] Error 1
This turns out to be an intentional change in binutils. ThumbEE was dropped
ahead of ARM v8 (i.e. AArch64).
Xen supports ARM v7+virt extensions so in principle we could #ifdef
CONFIG_ARM_32 to keep it working. However, there was apparently no use of
ThumbEE outside of demo code, so simply drop it.
On ThumbEE capable hardware, unconditionally trap ThumbEE instructions, and
drop the context switching logic for TEE{CR,HBR}32.
Reported-by: Hans van Kranenburg <hans@knorrie.org>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
In sha2_256_transform(), make state be an array of 8 rather than a pointer,
which lets the compiler do slightly more checking.
For better or worse, the canonical API in Linux is just the algorithm name.
As we're intending to import more from Linux in this area, drop the digest
suffix before we gain more users.
Compile sha2-256.o for all architectures. It's not very much code, and it
will be omitted at link time.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
We have two different functions explaining that DE_CFG is Core-scoped and that
writes are racy but happen to be safe. This is only true when there's one of
them.
Introduce amd_init_de_cfg() to be the singular function which writes to
DE_CFG, modelled after the logic we already have for BP_CFG.
While reworking amd_check_zenbleed() into a simple predicate used by
amd_init_de_cfg(), fix the microcode table. The 'good_rev' was specific to an
individual stepping and not valid to be matched by model, let alone a range.
The only CPUs incorrectly matched that I can locate appear to be
pre-production, and probably didn't get Zenbleed microcode.
Rework amd_init_lfence() to be amd_init_lfence_dispatch() with only the
purpose of configuring X86_FEATURE_LFENCE_DISPATCH in the case that it needs
synthesising. Run it on the BSP only and use setup_force_cpu_cap() to prevent
the bit disappearing on a subseuqent CPUID rescan.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
A XenServer feature in the process of being upstreamed is to be able to
re-calculate the guest CPU Policies at runtime, e.g. after a microcode load
and/or livepatch to expose new functionality. Right now, upstream Xen only
rescans the Raw CPU Policy on microcode load.
One complication with recalculating the guest policies is that BTC_NO is
handled differently to other $FOO_NO bits, by using __set_bit() rather than
setup_force_cpu_cap().
For consistency, switch it to using setup_force_cpu_cap(). This doesn't
matter for upstream Xen right now, but it will ease upstreaming the feature.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
As noted in the command line documentation, these are both deprecated since
Xen 4.7 (2016), and are not fully effective on AMD CPUs starting from 2011.
Not realised at the time of writing the docs was that their use is also
incompatible with certain errata workarounds which edit the CPUID MSRs after
the levelling defaults are calculated.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
The comment was adjusted by myself in commit 51bd4bbdfd ("x86: drop
X86_FEATURE_3DNOW_ALT"), on the presumption that the underlying logic existed
for a good reason.
Having done further archaeology, it turns out to be vestigial technical debt
from the leadup to Linux 2.4 in November 2000.
Prior to "Massive cleanup of CPU detection and bug handling",
c->x86_capability was a single uint32_t containing cpuid(1).edx,
cpuid(0x80000001).edx, or a synthesis thereof. X86_FEATURE_AMD3D was defined
as the top bit this single uint32_t.
After "Massive cleanup of CPU detection and bug handling",
c->x86_capability became an array with AMD's extended feature leaf split
away from Intel's basic feature leaf.
AMD doc #20734-G states that 3DNow is only enumerated in the extended
feature leaf, and that other vendors where using this bit too. i.e. AMD
never produced a CPU which set bit 31 in the basic leaf, meaning that
there's nothing to clear out in the first place.
This logic looks like it was relevant in the pre-"Massive cleanup" world
but ought to have been dropped when c->x86_capability was properly split.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
This was potentially helpful when the chickenbit was the only mitigation and
microcode had not been released, but that was two years ago.
Zenbleed microcode has been avaialble since December 2023, and the subsequent
Entrysign signature vulnerability means that firmware updates block OS-loading
and more OS-loadable microcode will be produced for Zen2.
i.e. the Zenbleed fix is not going to appear at runtime these days.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Using typeof() in wait_for_state()/set_state() unnecesserily cryptic, and more
verbose than using a proper type.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
It's impossible for wait_for_state() to return false when looking for
LOADING_EXIT, so much so that the optimiser can drop the ASSERT()s.
No functional change.
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The xen-ucode utility is sensitive to the overall error as -EEXIST is a
special case for success, but the real error can get clobbered with -EBUSY.
This can be demonstrated most easily by force loading an old microcode, which
should yield -EIO but yields -EBUSY:
# xen-ucode /lib/firmware/amd-ucode/microcode_amd_fam17h.bin --force
Failed to update microcode. (err: Device or resource busy)
(XEN) 256 cores are to update their microcode
(XEN) microcode: CPU0 update rev 0x830107d to 0x830107c failed, result 0x830107d
(XEN) Late loading aborted: CPU0 failed to update ucode: -5
wait_for_state() returns false on encountering LOADING_EXIT. Right now, this
is always transformed into -EBUSY and passed back to callers.
However, control_thread_fn() can move directly to this state in the case of an
early error; it is not an error condition for APs, but the latest write into
stopmachine_data.fn_result wins, causing the real error, -EIO, to get
clobbered with -EBUSY.
Drop all the -EBUSY's, and treat hitting LOADING_EXIT as a success case. This
causes only a single error to be returned through stop_machine_run(), and
preserves the -EIO
# xen-ucode /lib/firmware/amd-ucode/microcode_amd_fam17h.bin --force
Failed to update microcode. (err: Input/output error)
(XEN) 256 cores are to update their microcode
(XEN) microcode: CPU0 update rev 0x830107d to 0x830107c failed, result 0x830107d
(XEN) Late loading aborted: CPU0 failed to update ucode: -5
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Mirroring the cleanup to rdmsr(), do the same to wrmsr(). It now has the same
API as wrmsrl(), but we'll want to drop that wrapper in due course.
It's telling that almost all remaining users pass in 0. Most are converted
directly to WRMSRNS, but a few are not.
MSR_VIRT_SPEC_CTRL is unconditionally intercepted and is orders of magnitude
more expensive than just serialising. In disable_lapic_nmi_watchdog(), the P4
case won't run on hardware which has anything more than plain WRMSR.
For CTR_WRITE() in op_model_athlon.c there is a logical change in behaviour,
but it's fixing a bug. Peformance counters typically get written to -(count)
as they generate an interrupt on overflow. The performance counters even in
the K8 were 48 bits wide, and this wrmsr() not being a wrmsrl() appears to
have been an oversight in commit b5103d692a ("x86 oprofile: use
rdmsrl/wrmsrl") which converted all other users, and appears to be the last
time there was an attempt to unify the MSR APIs.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
We want a consistent MSR API, and these want to be named rdmsr() and wrmsr(),
but not with their current APIs. The current rdmsr() flavours writing to
their parameters by name makes code that reads like invalid C, and is
unergonomic to use in lots of cases.
Change the API, and update the callers all in one go. Where appropriate,
update the write side to wrmsrns() as per the recommendation.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
The latest oxenstored from Xapi-project fails to start up:
launch-xenstore[1201]: Starting /usr/sbin/oxenstored...
launch-xenstore[1222]: Fatal error: exception
Dynlink.Error (Dynlink.Cannot_open_dll "Dynlink.Error (Dynlink.Cannot_open_dll
\"Failure(\\\"/usr/libexec/xen//ocaml/xsd_glue/xenctrl_plugin/domain_getinfo_v1.cmxs:
undefined symbol: xc_domain_getinfo_single\\\")\")")
This is because domain_getinfo_v1.cmxs isn't dynamically linked correctly.
Fill in the correct variable, and remove the xen prefix from xenctrl.
Reported-by: Edwin Török <edwin.torok@citrix.com>
Suggested-by: Edwin Török <edwin.torok@citrix.com>
Fixes: a6576011a4 ("ocaml/libs: Implement a dynamically-loaded plugin for Xenctrl.domain_getinfo")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
When Entrysign has been mitigated in firwmare, it is believed to be safe to
rely on the CPU patchloader again. This avoids us needing to maintain the
digest table for all new microcode indefinitely.
Relax the digest check when firmware looks to be up to date, and leave behind
a clear message when not.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
This is best-effort only. If a malicious microcode has been loaded prior to
Xen running, then all bets are off.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
After initial publication, the SB-7033 / CVE-2024-36347 bulletin was updated
to list Zen5 CPUs as vulnerable. Use Fam1ah as an upper bound, and adjust the
command line documentation.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
Fixes: 630e8875ab ("x86/ucode: Perform extra SHA2 checks on AMD Fam17h/19h microcode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
For Zen3-5 microcode blobs signed with the updated signature scheme, the
checksum field has been reused to be a min_revision field, referring to the
microcode revision which fixed Entrysign (SB-7033, CVE-2024-36347).
Cross-check this when trying to load microcode, but allow --force to override
it. If the signature scheme is genuinely different, a #GP will occur.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
EIO is not the only error that ucode_ops.apply_microcode() can produce.
EINVAL, EEXISTS and ENXIO can be generated too, each of which mean that Xen is
unhappy in some way with the proposed blob.
Some of these can be bypassed with --force, which will cause the parallel load
to be attempted.
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
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>
Andrew Cooper