Andrew Cooper [Fri, 23 Jun 2023 10:32:00 +0000 (11:32 +0100)]
x86/vmx: Perform VERW flushing later in the VMExit path
Broken out of the following patch because this change is subtle enough on its
own. See it for the rational of why we're moving VERW.
As for how, extend the trick already used to hold one condition in
flags (RESUME vs LAUNCH) through the POPing of GPRs.
Move the MOV CR earlier. Intel specify flags to be undefined across it.
Encode the two conditions we want using SF and PF. See the code comment for
exactly how.
Leave a comment to explain the lack of any content around
SPEC_CTRL_EXIT_TO_VMX, but leave the block in place. Sods law says if we
delete it, we'll need to reintroduce it.
This is part of XSA-452 / CVE-2023-28746.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monne [Mon, 11 Mar 2024 10:54:16 +0000 (11:54 +0100)]
x86/mm: fix detection of last L1 entry in modify_xen_mappings_lite()
The current logic to detect when to switch to the next L1 table is incorrectly
using l2_table_offset() in order to notice when the last entry on the current
L1 table has been reached.
It should instead use l1_table_offset() to check whether the index has wrapped
to point to the first entry, and so the next L1 table should be used.
Fixes: 8676092a0f16 ('x86/livepatch: Fix livepatch application when CET is active') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Nicola Vetrini [Mon, 11 Mar 2024 08:36:20 +0000 (09:36 +0100)]
arm/smmu: address some violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Nicola Vetrini [Mon, 11 Mar 2024 08:35:50 +0000 (09:35 +0100)]
x86/irq: parenthesize negative constants
These constants are parenthesized to avoid them from
possibly influencing the semantics of the constructs where it is used,
especially inside macros invocations.
This also resolves some violations of MISRA C Rule 20.7
("Expressions resulting from the expansion of macro parameters shall
be enclosed in parentheses").
Nicola Vetrini [Mon, 11 Mar 2024 08:35:24 +0000 (09:35 +0100)]
xen/arm: address some violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Nicola Vetrini [Mon, 11 Mar 2024 08:34:45 +0000 (09:34 +0100)]
xen/param: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Nicola Vetrini [Mon, 11 Mar 2024 08:34:14 +0000 (09:34 +0100)]
xen/include: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Nicola Vetrini [Mon, 11 Mar 2024 08:33:55 +0000 (09:33 +0100)]
xen/spinlock: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Jason Andryuk [Mon, 11 Mar 2024 08:33:35 +0000 (09:33 +0100)]
xen/x86: bzImage parse kernel_alignment
Expand bzimage_parse() to return kernel_alignment from the setup_header.
This will be needed if loading a PVH kernel at a physical offset to
compensate for a reserved E820 region.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Jan Beulich <jbeulich@suse.com>
Currently direct mapped domain is only supported by the Arm
architecture at the domain creation time by setting the CDF_directmap
flag. There is not a need for every non-Arm architecture, i.e. x86,
RISC-V and PPC, to define a stub is_domain_direct_mapped() in arch
header.
Move is_domain_direct_mapped() to a centralized place at xen/domain.h
and evaluate CDF_directmap for non-Arm architecture to 0.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Henry Wang <xin.wang2@amd.com> Reviewed-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Mon, 11 Mar 2024 08:31:31 +0000 (09:31 +0100)]
MAINTAINERS: drop AMD SVM and Intel VT-x sections
We'd like to thank the VT-x maintainers for their past contributions,
while at the same time we'd like to reflect reality as it has been for
quite some time. Have VT-x maintainership (and for symmetry also AMD
SVM's) fall back to general x86.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
Oleksii Kurochko [Mon, 11 Mar 2024 08:30:29 +0000 (09:30 +0100)]
xen/mem-access: ifdef inclusion of <asm/mem_access.h>
ifdefing inclusion of <asm/mem_access.h> in <xen/mem_access.h>
allows to avoid generation of empty <asm/mem_access.h> header
for the case when !CONFIG_MEM_ACCESS.
For Arm it was explicitly added inclusion of <asm/mem_access.h> for p2m.c
and traps.c because they require some functions from <asm/mem_access.h> which
aren't available in case of !CONFIG_MEM_ACCESS.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com> Acked-by: Julien Grall <jgrall@amazon.com> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Henry Wang [Thu, 7 Mar 2024 13:56:16 +0000 (21:56 +0800)]
tools/9pfsd: Fix build error caused by strerror_r
Below error can be seen when doing Yocto build of the toolstack:
| io.c: In function 'p9_error':
| io.c:684:5: error: ignoring return value of 'strerror_r' declared
with attribute 'warn_unused_result' [-Werror=unused-result]
| 684 | strerror_r(err, ring->buffer, ring->ring_size);
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| cc1: all warnings being treated as errors
Using strerror_r() without special casing different build environments
is impossible due to the different return types (int vs char *)
depending on the environment. As p9_error() is not on a performance
critical path, using strerror() with a mutex ought to be fine. So,
fix the build by using strerror() to replace strerror_r(). The steps
would then become: Acquire the mutex first, invoke strerror(), copy
the string from strerror() to the designated buffer and then drop the
mutex.
Fixes: f4900d6d69b5 ("9pfsd: allow building with old glibc") Signed-off-by: Henry Wang <xin.wang2@amd.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Andrew Cooper [Tue, 5 Mar 2024 11:39:19 +0000 (11:39 +0000)]
x86/livepatch: Relax permissions on rodata too
This reinstates the capability to patch .rodata in load/unload hooks, which
was lost when we stopped using CR0.WP=0 to patch.
This turns out to be rather less of a large TODO than I thought at the time.
Fixes: 8676092a0f16 ("x86/livepatch: Fix livepatch application when CET is active") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Andrew Cooper [Tue, 5 Mar 2024 11:35:12 +0000 (11:35 +0000)]
xen/virtual-region: Include rodata pointers
These are optional. .init doesn't distinguish types of data like this, and
livepatches don't necesserily have any .rodata either.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Andrew Cooper [Tue, 5 Mar 2024 11:28:33 +0000 (11:28 +0000)]
xen/virtual-region: Rename the start/end fields
... to text_{start,end}. We're about to introduce another start/end pair.
Despite it's name, struct virtual_region has always been a module-ish
description. Call this out specifically.
As minor cleanup, replace ROUNDUP(x, PAGE_SIZE) with the more concise
PAGE_ALIGN() ahead of duplicating the example.
No functional change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Juergen Gross [Thu, 7 Mar 2024 08:18:04 +0000 (09:18 +0100)]
SUPPORT.md: add xen-9pfsd
Add a support statement for the new xen-9pfsd backend. Set it to
"Experimental", as some functionality for Linux guests is missing
(only tested to work with Xenstore-stubdom).
Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Thu, 7 Mar 2024 08:17:26 +0000 (09:17 +0100)]
x86/asm: add commas to further macros definitions/invocations
In light of recent observations with how macros are handled by gas,
let's play by what we informally set for ourselves as a guideline: Use
commas to separate parameters/arguments.
Requested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 7 Mar 2024 08:16:13 +0000 (09:16 +0100)]
x86/asm: add commas to BUILD_BUG_ON
In light of recent observations with how macros are handled by gas,
let's play by what we informally set for ourselves as a guideline: Use
commas to separate parameters/arguments.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 7 Mar 2024 08:15:17 +0000 (09:15 +0100)]
Kbuild: simplify as-insn a little
As of 732571959f17 ("xen/build: use new $(c_flags) and $(a_flags)
instead of $(CFLAGS)") -M options aren't part of CFLAGS anymore, and
c_flags isn't supposed to be passed to this macro. Drop the now dead
part of filtering.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Thu, 7 Mar 2024 08:14:55 +0000 (09:14 +0100)]
x86/EFI: correct compiler probing
Passing in $(CFLAGS) means also requesting inclusion of certain headers
(via -include command line options). That's particularly xen/config.h,
which in turn requires generated/autoconf.h. This has not caused any
problems so far only because arch.mk is processed twice, and the missing
header on the 1st pass would be there on the 2nd. Having added an
inclusion of asm/asm-macros.h to x86'es asm/config.h, the 2nd pass then
also fails on an initial, pristine build.
As per dd40177c1bc8 ("x86-64/EFI: add CFLAGS to check compile") dropping
the use of $(CFLAGS) altogether isn't an option, though. Hence remove
the problematic options only.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Jan Beulich [Tue, 5 Mar 2024 14:33:47 +0000 (15:33 +0100)]
9pfsd: allow building with old glibc
Neither pread() / pwrite() nor O_DIRECTORY are available from glibc
2.11.3 headers without defining (e.g.) _GNU_SOURCE. Supplying the
definition unconditionally shouldn't be a problem, seeing that various
other tools/ components do so, too.
Michal Orzel [Thu, 29 Feb 2024 12:13:52 +0000 (13:13 +0100)]
SUPPORT.md: clarify support of booting 32-bit Xen on ARMv8
Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on
unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs
in AArch32 state (assuming HW supports EL2 execution in AArch32). Clarify
the support statement and mark it as Tech Preview, as this use case is
uncommon and hasn't really been tested/hardened.
Signed-off-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Julien Grall <jgrall@amazon.com>
Jan Beulich [Wed, 6 Mar 2024 09:19:29 +0000 (10:19 +0100)]
hvmloader/PCI: skip huge BARs in certain calculations
BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
the lower 2Gb range and the top of the higher 2Gb range have special
purpose. Don't even have them influence whether to (perhaps) relocate
low RAM.
Reported-by: Neowutran <xen@neowutran.ovh> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Jan Beulich [Wed, 6 Mar 2024 09:17:36 +0000 (10:17 +0100)]
Argo: don't obtain excess page references
find_ring_mfn() already holds a page reference when trying to obtain a
writable type reference. We shouldn't make assumptions on the general
reference count limit being effectively "infinity". Obtain merely a type
ref, re-using the general ref by only dropping the previously acquired
one in the case of an error.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
Nicola Vetrini [Mon, 4 Mar 2024 09:47:14 +0000 (10:47 +0100)]
xen/tasklet: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Nicola Vetrini [Mon, 4 Mar 2024 09:46:46 +0000 (10:46 +0100)]
xen/errno: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Nicola Vetrini [Mon, 4 Mar 2024 09:46:25 +0000 (10:46 +0100)]
xen/arm: smmuv3: address violations of MISRA C Rule 20.7
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
Jan Beulich [Mon, 4 Mar 2024 09:45:10 +0000 (10:45 +0100)]
arch: move array_index_mask_nospec()
At the time they were introduced, there were no asm/nospec.h yet, so
they were placed in system.h. Move them to nospec.h and drop
xen/nospec.h's including of asm/system.h; there's one unrelated #include
that needs adding in exchange, on x86.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Julien Grall <jgrall@amazon.com>
Roger Pau Monné [Fri, 1 Mar 2024 12:42:27 +0000 (13:42 +0100)]
x86/mm: re-implement get_page_light() using an atomic increment
The current usage of a cmpxchg loop to increase the value of page count is not
optimal on amd64, as there's already an instruction to do an atomic add to a
64bit integer.
Switch the code in get_page_light() to use an atomic increment, as that avoids
a loop construct. This slightly changes the order of the checks, as current
code will crash before modifying the page count_info if the conditions are not
correct, while with the proposed change the crash will happen immediately
after having carried the counter increase. Since we are crashing anyway, I
don't believe the re-ordering to have any meaningful impact.
Note that the page must already have a non-zero reference count which prevents
the flags from changing, and the previous usage of the cmpxchg loop didn't
guarantee that the rest of the fields in count_info didn't change while
updating the reference count.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Andrew Cooper [Thu, 29 Feb 2024 11:26:40 +0000 (11:26 +0000)]
x86/cpu-policy: Allow for levelling of VERW side effects
MD_CLEAR and FB_CLEAR need OR-ing across a migrate pool. Allow this, by
having them unconditinally set in max, with the host values reflected in
default. Annotate the bits as having special properies.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Thu, 29 Feb 2024 20:46:13 +0000 (20:46 +0000)]
tests/resource: Fix HVM guest in !SHADOW builds
Right now, test-resource always creates HVM Shadow guests. But if Xen has
SHADOW compiled out, running the test yields:
$./test-resource
XENMEM_acquire_resource tests
Test x86 PV
Created d1
Test grant table
Test x86 PVH
Skip: 95 - Operation not supported
and doesn't really test HVM guests, but doesn't fail either.
There's nothing paging-mode-specific about this test, so default to HAP if
possible and provide a more specific message if neither HAP or Shadow are
available.
As we've got physinfo to hand, also provide more specific message about the
absence of PV or HVM support.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Wed, 28 Feb 2024 20:22:24 +0000 (20:22 +0000)]
x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies
The block in recalculate_cpuid_policy() predates the proper split between
default and max policies, and was a "slightly max for a toolstack which knows
about it" capability. It didn't get transformed properly in Xen 4.14.
Because Xen will accept a VM with HTT/CMP_LEGACY seen, they should be visible
in the max polices. Keep the default policy matching host settings.
This manifested as an incorrectly-rejected migration across XenServer's Xen
4.13 -> 4.17 upgrade, as Xapi is slowly growing the logic to check a VM
against the target max policy.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Andrew Cooper [Wed, 28 Feb 2024 20:21:58 +0000 (20:21 +0000)]
x86/cpu-policy: Hide x2APIC from PV guests
PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they
access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC
CPUID bit saying that they can.
Right now, the host x2APIC flag filters into PV guests, meaning that PV guests
generally see x2APIC except on Zen1-and-older AMD systems.
Linux works around this by explicitly hiding the bit itself, and filtering
EXTD out of MSR_APIC_BASE reads. NetBSD behaves more in the spirit of PV
guests, and entirely ignores the APIC when built as a PV guest.
Change the annotation from !A to !S. This has a consequence of stripping it
out of both PV featuremasks. However, as existing guests may have seen the
bit, set it back into the PV Max policy; a VM which saw the bit and is alive
enough to migrate will have ignored it one way or another.
Hiding x2APIC does change the contents of leaf 0xb, but as the information is
nonsense to begin with, this is likely an improvement on the status quo.
Xen's blind assumption that APIC_ID = vCPU_ID * 2 isn't interlinked with the
host's topology structure, where a PV guest may see real host values, and the
APIC_IDs are useless without an MADT to start with. Dom0 is the only PV VM to
get an MADT but it's the host one, meaning the two sets of APIC_IDs are from
different address spaces.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Michal Orzel [Fri, 1 Mar 2024 08:49:47 +0000 (09:49 +0100)]
docs/misra/rules.rst: Fix entry for 20.12 rule
Commit 4cac80e22600 broke the CI cppcheck jobs by adding an entry for
a rule 20.12 with "Severity" and "Summary" fields placed in reverse order.
This leads to an error as reported by convert_misra_doc.py:
No summary for rule 20.12
Fixes: 4cac80e22600 ("docs/misra/rules.rst: add rule 16.6 and 20.12") Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Roger Pau Monné [Thu, 29 Feb 2024 16:00:40 +0000 (17:00 +0100)]
pci: fix locking around vPCI removal in pci_remove_device()
Currently vpci_deassign_device() is called without holding the per-domain
pci_lock in pci_remove_device(), which leads to:
Assertion 'rw_is_write_locked(&pdev->domain->pci_lock)' failed at ../drivers/vpci/vpci.c:47
[...]
Xen call trace:
[<ffff82d040260eac>] R vpci_deassign_device+0x10d/0x1b9
[<ffff82d04027932f>] S pci_remove_device+0x2b1/0x380
[<ffff82d040260bd0>] F pci_physdev_op+0x197/0x19e
[<ffff82d04032272d>] F do_physdev_op+0x342/0x12aa
[<ffff82d0402f067a>] F pv_hypercall+0x58e/0x62b
[<ffff82d0402012ba>] F lstar_enter+0x13a/0x140
Move the existing block that removes the device from the domain pdev_list ahead
and also issue the call to vpci_deassign_device() there. It's fine to remove
the device from the domain list of assigned devices, as further functions only
care that the pdev domain field is correctly set to the owner of the device
about to be removed.
Moving the vpci_deassign_device() past the pci_cleanup_msi() call can be
dangerous, as doing the MSI cleanup ahead of having removed the vPCI handlers
could lead to stale data in vPCI MSI(-X) internal structures.
Fixes: 4f78438b45e2 ('vpci: use per-domain PCI lock to protect vpci structure') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Juergen Gross [Thu, 29 Feb 2024 12:48:30 +0000 (13:48 +0100)]
tools/xenstored: have a single do_control_memreport()
With 9pfs now available in Xenstore-stubdom, there is no reason to
have distinct do_control_memreport() variants for the daemon and the
stubdom implementations.
Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com>
Juergen Gross [Thu, 29 Feb 2024 12:48:28 +0000 (13:48 +0100)]
tools/xenstored: add helpers for filename handling
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
just expand them to be relative to /var/lib/xen/xenstore)
- expansion of xenstore_daemon_rundir() (used e.g. for saving the state
file in case of live update - needs to be unchanged in the daemon
case, but should result in /var/lib/xen/xenstore for stubdom)
Oleksii Kurochko [Thu, 29 Feb 2024 15:58:34 +0000 (16:58 +0100)]
xen/riscv: introduce nospec.h
From the unpriviliged doc:
No standard hints are presently defined.
We anticipate standard hints to eventually include memory-system spatial
and temporal locality hints, branch prediction hints, thread-scheduling
hints, security tags, and instrumentation flags for simulation/emulation.
Also, there are no speculation execution barriers.
Therefore, functions evaluate_nospec() and block_speculation() should
remain empty until a specific platform has an extension to deal with
speculation execution.
Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Thu, 29 Feb 2024 07:21:49 +0000 (08:21 +0100)]
x86/altcall: always use a temporary parameter stashing variable
The usage in ALT_CALL_ARG() on clang of:
register union {
typeof(arg) e;
const unsigned long r;
} ...
When `arg` is the first argument to alternative_{,v}call() and
const_vlapic_vcpu() is used results in clang 3.5.0 complaining with:
arch/x86/hvm/vlapic.c:141:47: error: non-const static data member must be initialized out of line
alternative_call(hvm_funcs.test_pir, const_vlapic_vcpu(vlapic), vec) )
Workaround this by pulling `arg1` into a local variable, like it's done for
further arguments (arg2, arg3...)
Originally arg1 wasn't pulled into a variable because for the a1_ register
local variable the possible clobbering as a result of operators on other
variables don't matter:
Note clang version 3.8.1 seems to already be fixed and don't require the
workaround, but since it's harmless do it uniformly everywhere.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Fixes: 2ce562b2a413 ('x86/altcall: use a union as register type for function parameters on clang') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Simone Ballarin [Tue, 27 Feb 2024 15:36:30 +0000 (16:36 +0100)]
docs: Move function and macro properties in docs/misra
The list of function/macro properties is not MISRA-specific documentation.
Their addition was directly motivated to address MISRA findings and they
are not used elsewhere. For this reason, this patch moves these properties
in docs/misra.
This patch also fixes a Sphinx warning caused by the missing inclusion
of the rst file in the toctree.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Fixes: f4519ee8 ("eclair: move function and macro properties outside ECLAIR") Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Thu, 29 Feb 2024 07:19:22 +0000 (08:19 +0100)]
x86/memsharing: use an atomic add instead of a cmpxchg loop
The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
The cmpxchg usage is likely a remnant of 32bit support, which didn't have an
instruction to do an atomic 64bit add, and instead a cmpxchg had to be used.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-of-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com> Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Jason Andryuk [Thu, 29 Feb 2024 07:18:38 +0000 (08:18 +0100)]
libxl: Fix segfault in device_model_spawn_outcome
libxl__spawn_qdisk_backend() explicitly sets guest_config to NULL when
starting QEMU (the usual launch through libxl__spawn_local_dm() has a
guest_config though).
Bail early on a NULL guest_config/d_config. This skips the QMP queries
for chardevs and VNC, but this xenpv QEMU instance isn't expected to
provide those - only qdisk (or 9pfs backends after an upcoming change).
Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Roger Pau Monné [Tue, 27 Feb 2024 11:25:28 +0000 (12:25 +0100)]
xen/livepatch: group and document payload hooks
Group the payload hooks between the pre/post handlers, and the apply/revert
replacements. Also attempt to comment the context in which the hooks are
executed.
No functional change.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Roger Pau Monné [Tue, 27 Feb 2024 11:25:26 +0000 (12:25 +0100)]
xen/livepatch: fix norevert test attempt to open-code revert
The purpose of the norevert test is to install a dummy handler that replaces
the internal Xen revert code, and then perform the revert in the post-revert
hook. For that purpose the usage of the previous common_livepatch_revert() is
not enough, as that just reverts specific functions, but not the whole state of
the payload.
Remove both common_livepatch_{apply,revert}() and instead expose
revert_payload{,_tail}() in order to perform the patch revert from the
post-revert hook.
Fixes: 6047104c3ccc ('livepatch: Add per-function applied/reverted state tracking marker') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Roger Pau Monné [Tue, 27 Feb 2024 11:25:25 +0000 (12:25 +0100)]
xen/livepatch: search for symbols in all loaded payloads
When checking if an address belongs to a patch, or when resolving a symbol,
take into account all loaded livepatch payloads, even if not applied.
This is required in order for the pre-apply and post-revert hooks to work
properly, or else Xen won't detect the instruction pointer belonging to those
hooks as being part of the currently active text.
Move the RCU handling to be used for payload_list instead of applied_list, as
now the calls from trap code will iterate over the payload_list.
Fixes: 8313c864fa95 ('livepatch: Implement pre-|post- apply|revert hooks') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Roger Pau Monné [Tue, 27 Feb 2024 11:25:24 +0000 (12:25 +0100)]
xen/livepatch: register livepatch regions when loaded
Currently livepatch regions are registered as virtual regions only after the
livepatch has been applied.
This can lead to issues when using the pre-apply or post-revert hooks, as at
that point the livepatch is not in the virtual regions list. If a livepatch
pre-apply hook contains a WARN() it would trigger an hypervisor crash, as the
code to handle the bug frame won't be able to find the instruction pointer that
triggered the #UD in any of the registered virtual regions, and hence crash.
Fix this by adding the livepatch payloads as virtual regions as soon as loaded,
and only remove them once the payload is unloaded. This requires some changes
to the virtual regions code, as the removal of the virtual regions is no longer
done in stop machine context, and hence an RCU barrier is added in order to
make sure there are no users of the virtual region after it's been removed from
the list.
Fixes: 8313c864fa95 ('livepatch: Implement pre-|post- apply|revert hooks') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Michal Orzel [Wed, 28 Feb 2024 10:35:55 +0000 (11:35 +0100)]
xen/arm: Fix arm32 build failure when early printk is enabled
Commit 0441c3acc7e9 forgot to rename FIXMAP_CONSOLE to FIX_CONSOLE in
TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro. This results in a build
failure on arm32, when early printk is enabled:
arch/arm/arm32/mmu/head.S:311: Error: invalid operands (*UND* and *ABS* sections) for `*'
Fixes: 0441c3acc7e9 ("xen/arm: fixmap: Rename the fixmap slots to follow the x86 convention") Signed-off-by: Michal Orzel <michal.orzel@amd.com> Acked-by: Julien Grall <jgrall@amazon.com>
xen/lib: introduce generic find next bit operations
find-next-bit.c is common for Arm64, PPC and RISCV64,
so it is moved to xen/lib.
PPC has been transitioned to generic functions from find-next-bit.c
since it now shares the same implementation as the PPC-specific code.
The MISRA exclude list has been updated to verify
lib/find-next-bit.c instead of Arm's find_next_bit.c,
as Arm's find_next_bit.c has been relocated to xen/lib/.
Despite CONFIG_GENERIC_FIND_FIRST_BIT not currently being used in
Xen and being removed from the Linux kernel [1], it could theoretically
prove useful for Xen. This is because the Linux kernel transitioned
Arm to the generic version of find_first_bit() and
find_first_zero_bit() due to improvements [1] in both performance
and .text size.
It would be prudent to investigate whether [1] is applicable to Xen
as well and, if so, implement the necessary changes in a separate patch.
The recent vPCI locking broke the vPCI unit tests. Fix it to unblock CI.
Fixes: 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci structure") Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Roger Pau Monné [Tue, 27 Feb 2024 13:58:40 +0000 (14:58 +0100)]
x86/spec: do not print thunk option selection if not built-in
Since the thunk built-in enable is printed as part of the "Compiled-in
support:" line, avoid printing anything in "Xen settings:" if the thunk is
disabled at build time.
Note the BTI-Thunk option printing is also adjusted to print a colon in the
same way the other options on the line do.
Requested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Tue, 27 Feb 2024 13:58:20 +0000 (14:58 +0100)]
x86/spec: fix INDIRECT_THUNK option to only be set when build-enabled
Attempt to provide a more helpful error message when the user attempts to set
spec-ctrl=bti-thunk option but the support is build-time disabled.
While there also adjust the command line documentation to mention
CONFIG_INDIRECT_THUNK instead of INDIRECT_THUNK.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Take into account guest's BAR view and program its p2m accordingly:
gfn is guest's view of the BAR and mfn is the physical BAR value.
This way hardware domain sees physical BAR values and guest sees
emulated ones.
Hardware domain continues getting the BARs identity mapped, while for
domUs the BARs are mapped at the requested guest address without
modifying the BAR address in the device PCI config space.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Instead of handling a single range set, that contains all the memory
regions of all the BARs and ROM, have them per BAR.
As the range sets are now created when a PCI device is added and destroyed
when it is removed so make them named and accounted.
Note that rangesets were chosen here despite there being only up to
3 separate ranges in each set (typically just 1). But rangeset per BAR
was chosen for the ease of implementation and existing code re-usability.
Also note that error handling of vpci_process_pending() is slightly
modified, and that vPCI handlers are no longer removed if the creation
of the mappings in vpci_process_pending() fails, as that's unlikely to
lead to a functional device in any case.
This is in preparation of making non-identity mappings in p2m for the MMIOs.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
There are range sets which should not be printed, so introduce a flag
which allows marking those as such. Implement relevant logic to skip
such entries while printing.
While at it also simplify the definition of the flags by directly
defining those without helpers.
Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
vpci/header: implement guest BAR register handlers
Add relevant vpci register handlers when assigning PCI device to a domain
and remove those when de-assigning. This allows having different
handlers for different domains, e.g. hwdom and other guests.
Emulate guest BAR register values: this allows creating a guest view
of the registers and emulates size and properties probe as it is done
during PCI device enumeration by the guest.
All empty, IO and ROM BARs for guests are emulated by returning 0 on
reads and ignoring writes: this BARs are special with this respect as
their lower bits have special meaning, so returning default ~0 on read
may confuse guest OS.
Introduce is_hwdom convenience variable and convert an existing
is_hardware_domain() check.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Introduce "fail" label in init_header() function to have the centralized
error return path. This is the pre-requirement for the future changes
in this function.
This patch does not introduce functional changes.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
vpci: restrict unhandled read/write operations for guests
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make sure only hardware domain can access the hardware directly
and restrict guests from doing so.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
vpci: use per-domain PCI lock to protect vpci structure
Use the per-domain PCI read/write lock to protect the presence of the
pci device vpci field. This lock can be used (and in a few cases is used
right away) so that vpci removal can be performed while holding the lock
in write mode. Previously such removal could race with vpci_read for
example.
When taking both d->pci_lock and pdev->vpci->lock, they should be
taken in this exact order: d->pci_lock then pdev->vpci->lock to avoid
possible deadlock situations.
1. Per-domain's pci_lock is used to protect pdev->vpci structure
from being removed.
2. Writing the command register and ROM BAR register may trigger
modify_bars to run, which in turn may access multiple pdevs while
checking for the existing BAR's overlap. The overlapping check, if
done under the read lock, requires vpci->lock to be acquired on both
devices being compared, which may produce a deadlock. It is not
possible to upgrade read lock to write lock in such a case. So, in
order to prevent the deadlock, use d->pci_lock in write mode instead.
All other code, which doesn't lead to pdev->vpci destruction and does
not access multiple pdevs at the same time, can still use a
combination of the read lock and pdev->vpci->lock.
3. Drop const qualifier where the new rwlock is used and this is
appropriate.
4. Do not call process_pending_softirqs with any locks held. For that
unlock prior the call and re-acquire the locks after. After
re-acquiring the lock there is no need to check if pdev->vpci exists:
- in apply_map because of the context it is called (no race condition
possible)
- for MSI/MSI-X debug code because it is called at the end of
pdev->vpci access and no further access to pdev->vpci is made
5. Use d->pci_lock around for_each_pdev and pci_get_pdev()
while accessing pdevs in vpci code.
6. Switch vPCI functions to use per-domain pci_lock for ensuring pdevs
do not go away. The vPCI functions call several MSI-related functions
which already have existing non-vPCI callers. Change those MSI-related
functions to allow using either pcidevs_lock() or d->pci_lock for
ensuring pdevs do not go away. Holding d->pci_lock in read mode is
sufficient. Note that this pdev protection mechanism does not protect
other state or critical sections. These MSI-related functions already
have other race condition and state protection mechanims (e.g.
d->event_lock and msixtbl RCU), so we deduce that the use of the global
pcidevs_lock() is to ensure that pdevs do not go away.
7. Introduce wrapper construct, pdev_list_is_read_locked(), for checking
that pdevs do not go away. The purpose of this wrapper is to aid
readability and document the intent of the pdev protection mechanism.
8. When possible, the existing non-vPCI callers of these MSI-related
functions haven't been switched to use the newly introduced per-domain
pci_lock, and will continue to use the global pcidevs_lock(). This is
done to reduce the risk of the new locking scheme introducing
regressions. Those users will be adjusted in due time. One exception
is where the pcidevs_lock() in allocate_and_map_msi_pirq() is moved to
the caller, physdev_map_pirq(): this instance is switched to
read_lock(&d->pci_lock) right away.
Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
Jan Beulich [Tue, 27 Feb 2024 12:49:52 +0000 (13:49 +0100)]
x86: re-run exception-from-stub recovery selftests with CET-SS enabled
On the BSP, shadow stacks are enabled only relatively late in the
booting process. They in particular aren't active yet when initcalls are
run. Keep the testing there, but invoke that testing a 2nd time when
shadow stacks are active, to make sure we won't regress that case after
addressing XSA-451.
While touching this code, switch the guard from NDEBUG to CONFIG_DEBUG,
such that IS_ENABLED() can validly be used at the new call site.
Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jan Beulich [Tue, 27 Feb 2024 12:49:22 +0000 (13:49 +0100)]
x86: account for shadow stack in exception-from-stub recovery
Dealing with exceptions raised from within emulation stubs involves
discarding return address (replaced by exception related information).
Such discarding of course also requires removing the corresponding entry
from the shadow stack.
Also amend the comment in fixup_exception_return(), to further clarify
why use of ptr[1] can't be an out-of-bounds access.
While touching do_invalid_op() also add a missing fall-through
annotation.
This is CVE-2023-46841 / XSA-451.
Fixes: 209fb9919b50 ("x86/extable: Adjust extable handling to be shadow stack compatible") Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Jens Wiklander [Tue, 13 Feb 2024 11:13:36 +0000 (12:13 +0100)]
xen/arm: ffa: reclaim shared memory on guest destroy
When an FF-A enabled guest is destroyed it may leave behind memory
shared with SPs. This memory must be reclaimed before it's reused or an
SP may make changes to memory used by a new unrelated guest. So when the
domain is teared down add FF-A requests to reclaim all remaining shared
memory.
SPs in the secure world are notified using VM_DESTROYED that a guest has
been destroyed. An SP is supposed to relinquish all shared memory to allow
reclaiming the memory. The relinquish operation may need to be delayed if
the shared memory is for instance part of a DMA operation.
The domain reference counter is increased when the first FF-A shared
memory is registered and the counter is decreased again when the last
shared memory is reclaimed. If FF-A shared memory registrations remain
at the end of of ffa_domain_teardown() a timer is set to try to reclaim
the shared memory every second until the memory is reclaimed.
A few minor style fixes with a removed empty line here and an added new
line there.
xen/ppc: address violations of MISRA C:2012 Rule 11.8
The xen sources contain violations of MISRA C:2012 Rule 11.8 whose
headline states:
"A conversion shall not remove any const, volatile or _Atomic qualification
from the type pointed to by a pointer".
Fix violation by adding missing const qualifier in cast.
Andrew Cooper [Sat, 27 Jan 2024 17:52:09 +0000 (17:52 +0000)]
x86/entry: Introduce EFRAME_* constants
restore_all_guest() does a lot of manipulation of the stack after popping the
GPRs, and uses raw %rsp displacements to do so. Also, almost all entrypaths
use raw %rsp displacements prior to pushing GPRs.
Provide better mnemonics, to aid readability and reduce the chance of errors
when editing.
No functional change. The resulting binary is identical.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Andrew Cooper [Tue, 20 Feb 2024 20:53:15 +0000 (20:53 +0000)]
x86/entry: Adjustments to "reduce assembly code size of entry points"
Some retroactive review, for if I'd got to the patch in time.
* The new ASM-friendly BUILD_BUG_ON() should be in a header file.
* entry_int82() wants the movl->movb treatment too.
Fixes: c144b9e32427 ("x86: Reduce assembly code size of entry points") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
George Dunlap [Mon, 22 Jan 2024 15:32:25 +0000 (15:32 +0000)]
nestedsvm: Remove bogus debug message from nestedsvm_check_intercepts
Changeset ef3e8db8068 ("x86/hvm: Corrections and improvements to
unhandled vmexit logging") introduced a printk to the default path of
the switch statement in nestedsvm_check_intercepts(), complaining of
an unknown exit reason.
Unfortunately, the "core" switch statement which is meant to handle
all vmexit reasons is in nsvm_vmcb_guest_intercepts_exitcode(); the
switch statement in nestedsvm_check_intercepts() is only meant to
superimpose on top of that some special-casing for how to interaction
between L1 and L0 vmexits.
Remove the printk, and add a comment to prevent future confusion.
Fixes: ef3e8db8068 ("x86/hvm: Corrections and improvements to unhandled vmexit logging") Signed-off-by: George Dunlap <george.dunlap@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
George Dunlap [Wed, 17 Jan 2024 15:48:35 +0000 (15:48 +0000)]
xen/hvm: Move other hvm_function_table booleans into the caps bitfield
Moving them all together has several advantages:
* Collects them all in one part of the struct
* The `caps` field means that we can drop the "_supported" suffix, as it's
clear what is meant.
While here, replace some 0/1 values with false/true.
Signed-off-by: George Dunlap <george.dunlap@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
George Dunlap [Mon, 5 Feb 2024 21:42:59 +0000 (21:42 +0000)]
svm: Improve type of cpu_has_svm_feature
The "effective type" of the cpu_has_svm_feature macro is effectively
an unsigned log with one bit set (or not); at least one place someone
felt compelled to do a !! to make sure that they got a boolean out of
it.
Ideally the whole of this would be folded into the cpufeature.h
infrastructure. But for now, duplicate the more type-safe static
inlines in that file, and remove the !!.
Signed-off-by: George Dunlap <george.dunlap@cloud.com> Acked-by: Jan Beulich <jbeulich@suse.com>
George Dunlap [Mon, 15 Jan 2024 17:05:09 +0000 (17:05 +0000)]
xen/hvm: Convert hap_capabilities into a bitfield
hvm_function_table is an internal structure; rather than manually
|-ing and &-ing bits, just make it a boolean bitfield and let the
compiler do all the work. This makes everything easier to read, and
presumably allows the compiler more flexibility in producing efficient
code.
No functional change intended.
Signed-off-by: George Dunlap <george.dunlap@cloud.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
Roger Pau Monné [Mon, 26 Feb 2024 15:06:42 +0000 (16:06 +0100)]
x86/spec: fix BRANCH_HARDEN option to only be set when build-enabled
The current logic to handle the BRANCH_HARDEN option will report it as enabled
even when build-time disabled. Fix this by only allowing the option to be set
when support for it is built into Xen.
Fixes: 2d6f36daa086 ('x86/nospec: Introduce CONFIG_SPECULATIVE_HARDEN_BRANCH') Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
projects / xen.git / log