xen-project/xen
1
0 Fork 0
mirror of https://github.com/xen-project/xen.git synced 2026-10-28 02:01:24 +01:00
Code Issues Activity
46,751 Commits 53 Branches 377 Tags
f5c2b6da26d9becd5a1a03fcd3e5c950301030a2
Commit Graph
46751 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
Carlo Nonato f5c2b6da26 xen/page_alloc: introduce page flag to stop buddy merging 
Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
free_heap_pages() from merging pages that have it set. As of now, only
PGC_static has this feature, but future work can extend it easier than
before.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-21 09:47:21 +01:00
Carlo Nonato 75214d5e53 xen/page_alloc: introduce preserved page flags macro 
PGC_static and PGC_extra needs to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.

To make preserved flags even more meaningful, they are kept also when
switching state in mark_page_free().

Signed-off-by: Carlo Nonato <carlo.nonato@minervasys.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-21 09:46:42 +01:00
Elliott Mitchell 6eb13b6b1d tools/xl_parse: remove message for tsc mode string 
Normal behavior is to be silent.  Generating a message for the preferred
input can be mistaken for an error.  As such remove this message to match
other conditions.

Signed-off-by: Elliott Mitchell <ehem+xen@m5p.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
 2024-03-21 09:46:13 +01:00
Anthony PERARD eaafbd1134 docs/parse-support-md: Handle BulletList 
Commit d638e304f1 introduced a bullet list, but parse-support-md
choke on it as it doesn't know what to do about it.

Introduce ri_BulletList() so that r_content() will find this new
function and call it instead of calling process_unknown().

Reported-by: Julien Grall <julien@xen.org>
Fixes: d638e304f1 ("SUPPORT.MD: Fix matrix generation after 43c416d0d8 and 77c39a53cf5b")
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Tested-by: Julien Grall <jgrall@amazon.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-20 08:58:59 +00:00
Andrew Cooper 188fa82305 xen/vpci: Improve code generation in mask_write() 
The use of __clear_bit() forces dmask to be spilled to the stack, and
interferes with the compiler heuristcs for some upcoming improvements to the
ffs() code generation.

First, shrink dmask to just the active vectors by making out the upper bits.
This replaces the "i < msi->vectors" part of the loop condition.

Next, use a simple while() loop with "clear bottom bit" expressed in plane C,
which affords the optimiser a far better understanding of what the loop is
doing.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
 2024-03-19 18:29:37 +00:00
Andrew Cooper 131892e0dc x86/boot: Support the watchdog on newer AMD systems 
The MSRs used by setup_k7_watchdog() are architectural in 64bit.  The Unit
Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 25
years, making this a trend likely to continue.

Drop the family check.  If the Unit Select does happen to change meaning in
the future, check_nmi_watchdog() will still notice the watchdog not operating
as expected.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 18:29:37 +00:00
Andrew Cooper f658321374 x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly 
Right now, if the user requests the watchdog on the command line,
setup_apic_nmi_watchdog() will blindly assume that setting up the watchdog
worked.  Reuse nmi_perfctr_msr to identify when the watchdog has been
configured.

Rearrange setup_p6_watchdog() to not set nmi_perfctr_msr until the sanity
checks are complete.  Turn setup_p4_watchdog() into a void function, matching
the others.

If the watchdog isn't set up, inform the user and override to NMI_NONE, which
will prevent check_nmi_watchdog() from claiming that all CPUs are stuck.

e.g.:

  (XEN) alt table ffff82d040697c38 -> ffff82d0406a97f0
  (XEN) Failed to configure NMI watchdog
  (XEN) Brought up 512 CPUs
  (XEN) Scheduling granularity: cpu, 1 CPU per sched-resource

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 18:29:37 +00:00
Andrew Cooper 9e18f33983 x86/boot: Improve the boot watchdog determination of stuck cpus 
Right now, check_nmi_watchdog() has two processing loops over all online CPUs
using prev_nmi_count as storage.

Use a cpumask_t instead (1/32th as much initdata) and have wait_for_nmis()
make the determination of whether it is stuck, rather than having both
functions needing to agree on how many ticks mean stuck.

More importantly though, it means we can use the standard cpumask
infrastructure, including turning this:

  (XEN) Brought up 512 CPUs
  (XEN) Testing NMI watchdog on all CPUs: {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511} stuck

into the rather more manageable:

  (XEN) Brought up 512 CPUs
  (XEN) Testing NMI watchdog on all CPUs: {0-511} stuck

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
 2024-03-19 18:29:37 +00:00
Michal Orzel d2276b86e5 xen/nospec: Include <xen/stdbool.h> 
After introduction of lock_evaluate_nospec() using bool type, building
Xen on Arm with UBSAN enabled fails:

In file included from ./include/xen/spinlock.h:4,
                 from common/ubsan/ubsan.c:13:
./include/xen/nospec.h:79:22: error: unknown type name ‘bool’
   79 | static always_inline bool lock_evaluate_nospec(bool condition)

There is no issue on x86, as xen/stdbool.h is included somewhere along
the asm/nospec.h path, which is not the case for other architectures.

Fixes: 7ef0084418 ("x86/spinlock: introduce support for blocking speculation into critical regions")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 11:30:30 +01:00
Nicola Vetrini d9e709e8c0 xen/wait: 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>
 2024-03-19 11:30:01 +01:00
Nicola Vetrini 239b72d874 xen/notifier: 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>
 2024-03-19 11:29:12 +01:00
Nicola Vetrini 88822d5fbd xen/arm: smmu: 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>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
 2024-03-19 11:28:44 +01:00
Nicola Vetrini 8e7207d512 EFI: 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>
 2024-03-19 11:28:28 +01:00
Nicola Vetrini b51d7f39dc xen/device_tree: 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>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
 2024-03-19 11:27:58 +01:00
Nicola Vetrini 9979cc594a x86/cpufeature: add parentheses to comply with 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>
 2024-03-19 11:27:29 +01:00
Nicola Vetrini a02174c6c8 amd/iommu: clean up unused guest iommu related functions 
Delete unused functions from 'iommu_guest.c'.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 11:27:07 +01:00
Juergen Gross b053075d1a xen/spinlock: make struct lock_profile rspinlock_t aware 
Struct lock_profile contains a pointer to the spinlock it is associated
with. Prepare support of differing spinlock_t and rspinlock_t types by
adding a type indicator of the pointer. Use the highest bit of the
block_cnt member for this indicator in order to not grow the struct
while hurting only the slow path with slightly less performant code.
Note that this requires a cast when printing the value in order to be
format compliant.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Alejandro Vallejo <alejandro.vallejo@cloud.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-19 11:26:34 +01:00
Juergen Gross cc3e8df542 xen/spinlock: add rspin_[un]lock_irq[save|restore]() 
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.

Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 11:25:59 +01:00
Juergen Gross c9aca2a1f6 xen/spinlock: rename recursive lock functions 
Rename the recursive spin_lock() functions by replacing the trailing
"_recursive" with a leading "r".

Switch the parameter to be a pointer to rspinlock_t.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 11:25:07 +01:00
Juergen Gross 475080b6b2 xen/spinlock: introduce new type for recursive spinlocks 
Introduce a new type "rspinlock_t" to be used for recursive spinlocks.

For now it is only an alias of spinlock_t, so both types can still be
used for recursive spinlocks. This will be changed later, though.

Switch all recursive spinlocks to the new type.

Define the initializer helpers and use them where appropriate.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 11:23:53 +01:00
Marek Marczykowski-Górecki a97de92e76 IOMMU: store name for extra reserved device memory 
It will be useful for error reporting in a subsequent patch.

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-19 11:23:06 +01:00
Jan Beulich 62018f0870 x86/mm: use block_lock_speculation() in _mm_write_lock() 
I can only guess that using block_speculation() there was a leftover
from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
SPECULATIVE_HARDEN_BRANCH.

Fixes: 197ecd838a ("locking: attempt to ensure lock wrappers are always inline")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
 2024-03-18 13:53:37 +01:00
Nicola Vetrini d92a67b60c xen/sched: 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: George Dunlap <george.dunlap@cloud.com>
 2024-03-18 13:53:07 +01:00
Federico Serafini f93d8dd519 automation/eclair: allow parameter name "unused" 
Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
violations involving parameter name "unused" (with an optional
numeric suffix): it makes explicit the intention of not using such
parameter within the function.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
 2024-03-18 13:52:53 +01:00
Wei Liu a5b90a90ee MAINTAINERS: remove myself from various positions 
I have not been active in the Xen community for some time. Update the
MAINTAINERS file to reflect reality.

Signed-off-by: Wei Liu <wl@xen.org>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
 2024-03-18 13:52:35 +01:00
Jan Beulich ad52857efc MAINTAINERS: drop AMD IOMMU and Intel VT-d sections 
We'd like to thank Kevin, so far the VT-d maintainer, for his past
contributions, while at the same time we'd like to reflect reality as it
has been for quite some time. Have VT-d maintainership (and for symmetry
also AMD IOMMU's) fall back to the maintainers of general x86. This also
brings things in sync with how they are for Arm.

While touching the X86 section also append two so far missing slashes.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
 2024-03-18 13:52:09 +01:00
Federico Serafini 8a8d5c22af perfc: add pseudo-keyword fallthrough 
Add pseudo-keyword fallthrough to make explicit the intention of the
code and meet requirements to deviate MISRA C:2012 Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause").

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-18 13:51:17 +01:00
Vaishali Thakkar 53b5208de8 x86/svmdebug: Print np, sev and sev_es vmcb bits 
Currently only raw _np_ctrl is being printed. It can
be informational to know about which particular bits
are enabled. So, this commit adds the bit-by-bit decode
for np, sev and sev_es bits.

Note that while, only np is enabled in certain scenarios
at the moment, work for enabling sev and sev_es is in
progress. And it'll be useful to have this information as
part of svmdebug.

Signed-off-by: Vaishali Thakkar <vaishali.thakkar@vates.tech>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-18 13:50:33 +01:00
Vaishali Thakkar 2f09f797ba x86/svm: Drop the suffix _guest from vmcb bit 
The suffix _guest is redundant for asid bit. Drop it
to avoid adding extra code volume.

While we're here, replace 0/1 with false/true and use
VMCB accessors instead of open coding.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Vaishali Thakkar <vaishali.thakkar@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-18 13:49:46 +01:00
Julien Grall d638e304f1 SUPPORT.MD: Fix matrix generation after 43c416d0d8 and 77c39a53cf 
The script docs/support-matrix-generate throw the following error on the
latest staging.

MDCCSR_EL0
DBGDTR_EL0
DBGDTRTX_EL0
DBGDTRRX_EL0
DBGDSCRINT
DBGDTRTXINT
DBGDTRRXINT
^ cannot parse status codeblock line:
MDCCSR_EL0
 ? at docs/parse-support-md line 172, <F> chunk 1.

With the current indentation, it looks like the script thinks this is
a status code block.

Solve the issue by switching to a bullet list.

Fixes: 43c416d0d8 ("xen/arm: arm64: Add emulation of Debug Data Transfer Registers")
Fixes: 77c39a53cf ("xen/arm: arm32: Add emulation of Debug Data Transfer Registers")
Signed-off-by: Julien Grall <jgrall@amazon.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
 2024-03-14 17:56:29 +00:00
Ayan Kumar Halder 77c39a53cf xen/arm: arm32: Add emulation of Debug Data Transfer Registers 
When user enables HVC_DCC config option in Linux, it invokes access to debug
transfer register (i.e. DBGDTRTXINT). As this register is not emulated, Xen
injects an undefined exception to the guest and Linux crashes.

To prevent this crash, introduce a partial emulation of DBGDTR[TR]XINT (these
registers share the same encoding) as RAZ/WI and DBGDSCRINT as TXfull.

Refer ARM DDI 0487J.a ID042523, G8.3.19, DBGDTRTXint:
"If TXfull is set to 1, set DTRTX to UNKNOWN".

As a pre-requisite, DBGOSLSR should be emulated in the same way as its AArch64
variant (i.e. OSLSR_EL1). This is to ensure that DBGOSLSR.OSLK is 0, which
allows us to skip the emulation of DBGDSCREXT (TXfull is treated as UNK/SBZP)
and focus on DBGDSCRINT. DBGOSLSR.OSLM[1] is set to 1 to mantain consistency
with Arm64.

Take the opportunity to fix the minimum EL for DBGDSCRINT, which should be 0.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-14 13:04:25 +00:00
Michal Orzel 43c416d0d8 xen/arm: arm64: Add emulation of Debug Data Transfer Registers 
Currently, if user enables HVC_DCC config option in Linux, it invokes access
to debug data transfer registers (i.e. DBGDTRTX_EL0 on arm64, DBGDTRTXINT on
arm32). As these registers are not emulated, Xen injects an undefined
exception to the guest and Linux crashes.

To prevent this crash, introduce a partial emulation of DBGDTR[TR]X_EL0
(these registers share the same encoding) as RAZ/WI and MDCCSR_EL0 as TXfull.

Refer ARM DDI 0487J.a ID042523, D19.3.8, DBGDTRTX_EL0
"If TXfull is set to 1, set DTRRX and DTRTX to UNKNOWN".

Thus, any OS is expected to read MDCCSR_EL0 and check for TXfull before
using DBGDTRTX_EL0. Linux does it via hvc_dcc_init() ---> hvc_dcc_check(),
and returns -ENODEV in case TXfull bit is still set after writing a test
character. This way we prevent the guest from making use of HVC DCC as a
console.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-14 13:04:25 +00:00
Ayan Kumar Halder bd06cf74fc xen/arm: Introduce CONFIG_PARTIAL_EMULATION and "partial-emulation" cmd option 
There can be situations when the registers cannot be emulated to their full
functionality. This can be due to the complexity involved. In such cases, one
can emulate those registers as RAZ/WI for example. We call them as partial
emulation.

Some registers are non-optional and as such there is nothing preventing an OS
from accessing them.
Instead of injecting undefined exception (which might result in crashing a
guest), one may want to prefer a partial emulation to let the guest running
(in some cases accepting the fact that it might result in unwanted behavior).

A suitable example of this (as seen in subsequent patches) is emulation of
DBGDTRTX_EL0 (on Arm64) and DBGDTRTXINT(on Arm32). These non-optional
registers can be emulated as RAZ/WI and they can be enclosed within
CONFIG_PARTIAL_EMULATION.

Further, "partial-emulation" command line option allows us to
enable/disable partial emulation at run time. While CONFIG_PARTIAL_EMULATION
enables support for partial emulation at compile time (i.e. adds code for
partial emulation), this option may be enabled or disabled by Yocto or other
build systems. However if the build system turns this option on, users
can use scripts like Imagebuilder to generate uboot-script which will append
"partial-emulation=true" to xen command line to turn on the partial emulation.
Thus, it helps to avoid rebuilding xen.

By default, "CONFIG_PARTIAL_EMULATION=y" and "partial-emulation=false".
This is done so that Xen supports partial emulation. However, customers are
fully aware when they enable partial emulation. It's important to note that
enabling such support might result in unwanted/non-spec compliant behavior.

Added a note in SUPPORT.md to clarify the security support for partial
emulation.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-14 13:04:25 +00:00
Juergen Gross af7fed3fdf xen/spinlock: remove misra rule 21.1 violations 
In xen spinlock code there are several violations of MISRA rule 21.1
(identifiers starting with "__" or "_[A-Z]").

Fix them by using trailing underscores instead.

Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-14 13:55:55 +01:00
Federico Serafini 68e008db0c xen: avoid grep fodder define and undef 
Place an "#if 0" before grep fodder #define-s and remove
the #undef-s.

This addresses violations of MISRA C:2012 Rules 20.5 ("#undef should
not be used") and 5.5 ("Identifiers shall be distinct from macro
names").

No functional change.

Signed-off-by: Federico Serafini <federico.serafini@bugseng.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
 2024-03-14 13:55:27 +01:00
Paul Durrant 70e549fd44 MAINTAINERS: Remove myself from several subsystems 
I am not as actively involved with the Xen project as I once was so I need
to relinquish some of my maintainer responsibilities: IOMMU and I/O
emulation.

NOTE: Since I am sole maintainer for I/O EMULATION (IOREQ) and
      X86 I/O EMULATION, these sections are removed.

Signed-off-by: Paul Durrant <pdurrant@amazon.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
 2024-03-14 13:55:11 +01:00
Vaishali Thakkar a6081d0176 x86/svm: Drop the _enabled suffix from vmcb bits 
The suffix is redundant for np/sev/sev-es bits. Drop it
to avoid adding extra code volume.

Also, while we're here, drop the double negations in one
of the instances of _np bit, replace 0/1 with false/true
in the use cases of _np and use VMCB accessors instead
of open coding.

Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Vaishali Thakkar <vaishali.thakkar@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
 2024-03-14 13:54:43 +01:00
Nicola Vetrini d2686bf964 xen/compiler: deviate the inline macro for MISRA C Rule 20.4 
Rule 20.4 states: "A macro shall not be defined with the same name
as a keyword".

Defining this macro with the same name as the inline keyword
allows for additionally checking that out-of-lined static inline
functions end up in the correct section while minimizing churn and
has a positive impact on the overall safety. See [1] for additional
context on the motivation of this deviation.

No functional change.

[1] https://lore.kernel.org/xen-devel/adaa6d55-266d-4df8-8967-9340080d17e4@citrix.com/

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
 2024-03-14 13:54:14 +01:00
Maria Celeste Cesario 3945b61ddb xen/lz4: address violations of MISRA C:2012 Directive 4.10 
Add inclusion guard to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
prevent the contents of a header file being included more than once").
Mechanical change.

Signed-off-by: Maria Celeste Cesario <maria.celeste.cesario@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-14 13:52:46 +01:00
Maria Celeste Cesario ec2587ab4b x86/mtrr: address violations of MISRA C:2012 Directive 4.10 
Add inclusion guard to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
prevent the contents of a header file being included more than once").
Mechanical change.

Signed-off-by: Maria Celeste Cesario <maria.celeste.cesario@bugseng.com>
Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-14 13:52:32 +01:00
Jan Beulich 13a7b0f9f7 restrict concept of pIRQ to x86 
... by way of a new arch-selectable Kconfig control.

Note that some smaller pieces of code are left without #ifdef, to keep
things better readable. Hence items like ECS_PIRQ, nr_static_irqs, or
domain_pirq_to_irq() remain uniformly.

As to XEN_DOMCTL_irq_permission - this, despite having a uniformly
available wrapper in libxc, is unused on Arm: libxl bypasses those
calls, and the Python and OCamL bindings have no users at all.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-14 13:51:19 +01:00
Nicola Vetrini 4dc9a8b060 automation/eclair_analysis: deviate certain macros for Rule 20.12 
Certain macros are allowed to violate the Rule, since their meaning and
intended use is well-known to all Xen developers.

Variadic macros that rely on the GCC extension for removing a trailing
comma when token pasting the variable argument are similarly
well-understood and therefore allowed.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
 2024-03-13 17:21:51 -07:00
Roger Pau Monné 03cf7ca23e x86: protect conditional lock taking from speculative execution 
Conditionally taken locks that use the pattern:

if ( lock )
    spin_lock(...);

Need an else branch in order to issue an speculation barrier in the else case,
just like it's done in case the lock needs to be acquired.

eval_nospec() could be used on the condition itself, but that would result in a
double barrier on the branch where the lock is taken.

Introduce a new pair of helpers, {gfn,spin}_lock_if() that can be used to
conditionally take a lock in a speculation safe way.

This is part of XSA-453 / CVE-2024-2193

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Roger Pau Monné 42a572a38e x86/mm: add speculation barriers to open coded locks 
Add a speculation barrier to the clearly identified open-coded lock taking
functions.

Note that the memory sharing page_lock() replacement (_page_lock()) is left
as-is, as the code is experimental and not security supported.

This is part of XSA-453 / CVE-2024-2193

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Roger Pau Monné 197ecd838a locking: attempt to ensure lock wrappers are always inline 
In order to prevent the locking speculation barriers from being inside of
`call`ed functions that could be speculatively bypassed.

While there also add an extra locking barrier to _mm_write_lock() in the branch
taken when the lock is already held.

Note some functions are switched to use the unsafe variants (without speculation
barrier) of the locking primitives, but a speculation barrier is always added
to the exposed public lock wrapping helper.  That's the case with
sched_spin_lock_double() or pcidevs_lock() for example.

This is part of XSA-453 / CVE-2024-2193

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Roger Pau Monné f218daf6d3 percpu-rwlock: introduce support for blocking speculation into critical regions 
Add direct calls to block_lock_speculation() where required in order to prevent
speculation into the lock protected critical regions.  Also convert
_percpu_read_lock() from inline to always_inline.

Note that _percpu_write_lock() has been modified the use the non speculation
safe of the locking primites, as a speculation is added unconditionally by the
calling wrapper.

This is part of XSA-453 / CVE-2024-2193

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Roger Pau Monné a1fb15f616 rwlock: introduce support for blocking speculation into critical regions 
Introduce inline wrappers as required and add direct calls to
block_lock_speculation() in order to prevent speculation into the rwlock
protected critical regions.

Note the rwlock primitives are adjusted to use the non speculation safe variants
of the spinlock handlers, as a speculation barrier is added in the rwlock
calling wrappers.

trylock variants are protected by using lock_evaluate_nospec().

This is part of XSA-453 / CVE-2024-2193

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Roger Pau Monné 7ef0084418 x86/spinlock: introduce support for blocking speculation into critical regions 
Introduce a new Kconfig option to block speculation into lock protected
critical regions.  The Kconfig option is enabled by default, but the mitigation
won't be engaged unless it's explicitly enabled in the command line using
`spec-ctrl=lock-harden`.

Convert the spinlock acquire macros into always-inline functions, and introduce
a speculation barrier after the lock has been taken.  Note the speculation
barrier is not placed inside the implementation of the spin lock functions, as
to prevent speculation from falling through the call to the lock functions
resulting in the barrier also being skipped.

trylock variants are protected using a construct akin to the existing
evaluate_nospec().

This patch only implements the speculation barrier for x86.

Note spin locks are the only locking primitive taken care in this change,
further locking primitives will be adjusted by separate changes.

This is part of XSA-453 / CVE-2024-2193

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Andrew Cooper c4f427ec87 xen: Swap order of actions in the FREE*() macros 
Wherever possible, it is a good idea to NULL out the visible reference to an
object prior to freeing it.  The FREE*() macros already collect together both
parts, making it easy to adjust.

This has a marginal code generation improvement, as some of the calls to the
free() function can be tailcall optimised.

No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-12 15:50:04 +00:00
Andrew Cooper fb5b6f6744 x86/spec-ctrl: Mitigation Register File Data Sampling 
RFDS affects Atom cores, also branded E-cores, between the Goldmont and
Gracemont microarchitectures.  This includes Alder Lake and Raptor Lake hybrid
clien systems which have a mix of Gracemont and other types of cores.

Two new bits have been defined; RFDS_CLEAR to indicate VERW has more side
effets, and RFDS_NO to incidate that the system is unaffected.  Plenty of
unaffected CPUs won't be getting RFDS_NO retrofitted in microcode, so we
synthesise it.  Alder Lake and Raptor Lake Xeon-E's are unaffected due to
their platform configuration, and we must use the Hybrid CPUID bit to
distinguish them from their non-Xeon counterparts.

Like MD_CLEAR and FB_CLEAR, RFDS_CLEAR needs OR-ing across a resource pool, so
set it in the max policies and reflect the host setting in default.

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>
 2024-03-12 15:50:04 +00:00