xen-project/xen
1
0 Fork 1
mirror of https://github.com/xen-project/xen.git synced 2026-10-29 18:50:05 +01:00
Code Issues Activity
46,760 Commits 53 Branches 377 Tags
03e484a4f6fbf833f5b6fba3b8cebf43ca433f3a
Commit Graph
46760 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
Roger Pau Monné 03e484a4f6 x86/vcpu: relax VCPUOP_initialise restriction for non-PV vCPUs 
There's no reason to force HVM guests to have a valid vcpu_info area when
initializing a vCPU, as the vCPU can also be brought online using the local
APIC, and on that path there's no requirement for vcpu_info to be setup ahead
of the bring up.  Note an HVM vCPU can operate normally without making use of
vcpu_info, and in fact does so when brought up via the local APIC.

Restrict the check against dummy_vcpu_info to only apply to PV guests.

Fixes: 192df6f912 ('x86: allow HVM guests to use hypercalls to bring up vCPUs')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
 2024-03-25 10:48:23 +01:00
Oleksii Kurochko d654612e98 xen/riscv: add minimal stuff to processor.h to build full Xen 
The cpu_relax() function, introduced in this commit, is anticipated to
support _zihintpause by the CPU.

Signed-off-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
 2024-03-25 10:47:49 +01:00
Shawn Anastasio 5095b610df EFI: Introduce inline stub for efi_enabled on !X86 && !ARM 
On architectures with no EFI support, define an inline stub
implementation of efi_enabled in efi.h that always returns false.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Acked-by: Julien Grall <jgrall@amazon.com>
 2024-03-25 10:47:15 +01:00
Julien Grall cbe393b709 Revert "xen/page_alloc: introduce preserved page flags macro" 
Osstest is reporting a crash:

Mar 21 12:00:29.533676 (XEN) pg[0] MFN 2211c5 c=0x2c00000000000000 o=0 v=0xe40000010007ffff t=0x24
Mar 21 12:00:42.829785 (XEN) Xen BUG at common/page_alloc.c:1033
Mar 21 12:00:42.829829 (XEN) ----[ Xen-4.19-unstable  x86_64  debug=y  Not tainted ]----
Mar 21 12:00:42.829857 (XEN) CPU:    12
Mar 21 12:00:42.841571 (XEN) RIP:    e008:[<ffff82d04022fe1f>] common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
Mar 21 12:00:42.841609 (XEN) RFLAGS: 0000000000010282   CONTEXT: hypervisor (d0v8)
Mar 21 12:00:42.853654 (XEN) rax: ffff83023e3ed06c   rbx: 000000000007ffff   rcx: 0000000000000028
Mar 21 12:00:42.853689 (XEN) rdx: ffff83047bec7fff   rsi: ffff83023e3ea3e8   rdi: ffff83023e3ea3e0
Mar 21 12:00:42.865657 (XEN) rbp: ffff83047bec7c10   rsp: ffff83047bec7b98   r8:  0000000000000000
Mar 21 12:00:42.877647 (XEN) r9:  0000000000000001   r10: 000000000000000c   r11: 0000000000000010
Mar 21 12:00:42.877682 (XEN) r12: 0000000000000001   r13: 0000000000000000   r14: ffff82e0044238a0
Mar 21 12:00:42.889652 (XEN) r15: 0000000000000000   cr0: 0000000080050033   cr4: 0000000000372660
Mar 21 12:00:42.901651 (XEN) cr3: 000000046fe34000   cr2: 00007fb72757610b
Mar 21 12:00:42.901685 (XEN) fsb: 00007fb726def380   gsb: ffff88801f200000   gss: 0000000000000000
Mar 21 12:00:42.913646 (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
Mar 21 12:00:42.913680 (XEN) Xen code around <ffff82d04022fe1f> (common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2):
Mar 21 12:00:42.925645 (XEN)  d1 1c 00 e8 ad dd 02 00 <0f> 0b 48 85 c9 79 36 0f 0b 41 89 cd 48 c7 47 f0
Mar 21 12:00:42.937649 (XEN) Xen stack trace from rsp=ffff83047bec7b98:
Mar 21 12:00:42.937683 (XEN)    0000000000000024 000000007bec7c20 0000000000000001 ffff83046ccda000
Mar 21 12:00:42.949653 (XEN)    ffff82e000000021 0000000000000016 0000000000000000 0000000000000000
Mar 21 12:00:42.949687 (XEN)    0000000000000000 0000000000000000 0000000000000028 0000000000000021
Mar 21 12:00:42.961652 (XEN)    ffff83046ccda000 0000000000000000 00007d2000000000 ffff83047bec7c48
Mar 21 12:00:42.961687 (XEN)    ffff82d0402302ff ffff83046ccda000 0000000000000100 0000000000000000
Mar 21 12:00:42.973655 (XEN)    ffff82d0405f0080 00007d2000000000 ffff83047bec7c80 ffff82d0402f626c
Mar 21 12:00:42.985656 (XEN)    ffff83046ccda000 ffff83046ccda640 0000000000000000 0000000000000000
Mar 21 12:00:42.985690 (XEN)    ffff83046ccda220 ffff83047bec7cb0 ffff82d0402f65a0 ffff83046ccda000
Mar 21 12:00:42.997662 (XEN)    0000000000000000 0000000000000000 0000000000000000 ffff83047bec7cc0
Mar 21 12:00:43.009660 (XEN)    ffff82d040311f8a ffff83047bec7ce0 ffff82d0402bd543 ffff83046ccda000
Mar 21 12:00:43.009695 (XEN)    ffff83047bec7dc8 ffff83047bec7d08 ffff82d04032c524 ffff83046ccda000
Mar 21 12:00:43.021653 (XEN)    ffff83047bec7dc8 0000000000000002 ffff83047bec7d58 ffff82d040206750
Mar 21 12:00:43.033642 (XEN)    0000000000000000 ffff82d040233fe5 ffff83047bec7d48 0000000000000000
Mar 21 12:00:43.033678 (XEN)    0000000000000002 00007fb72767f010 ffff82d0405e9120 0000000000000001
Mar 21 12:00:43.045654 (XEN)    ffff83047bec7e70 ffff82d040240728 0000000000000007 ffff83023e3b3000
Mar 21 12:00:43.045690 (XEN)    0000000000000246 ffff83023e2efa90 ffff83023e38e000 ffff83023e2efb40
Mar 21 12:00:43.057609 (XEN)    0000000000000007 ffff83023e3afb80 0000000000000206 ffff83047bec7dc0
Mar 21 12:00:43.069662 (XEN)    0000001600000001 000000000000ffff e75aaa8d0000000c ac0d6d864e487f62
Mar 21 12:00:43.069697 (XEN)    000000037fa48d76 0000000200000000 ffffffff000003ff 00000002ffffffff
Mar 21 12:00:43.081647 (XEN)    0000000000000000 00000000000001ff 0000000000000000 0000000000000000
Mar 21 12:00:43.093646 (XEN) Xen call trace:
Mar 21 12:00:43.093677 (XEN)    [<ffff82d04022fe1f>] R common/page_alloc.c#alloc_heap_pages+0x37f/0x6e2
Mar 21 12:00:43.093705 (XEN)    [<ffff82d0402302ff>] F alloc_domheap_pages+0x17d/0x1e4
Mar 21 12:00:43.105652 (XEN)    [<ffff82d0402f626c>] F hap_set_allocation+0x73/0x23c
Mar 21 12:00:43.105685 (XEN)    [<ffff82d0402f65a0>] F hap_enable+0x138/0x33c
Mar 21 12:00:43.117646 (XEN)    [<ffff82d040311f8a>] F paging_enable+0x2d/0x45
Mar 21 12:00:43.117679 (XEN)    [<ffff82d0402bd543>] F hvm_domain_initialise+0x185/0x428
Mar 21 12:00:43.129652 (XEN)    [<ffff82d04032c524>] F arch_domain_create+0x3e7/0x4c1
Mar 21 12:00:43.129687 (XEN)    [<ffff82d040206750>] F domain_create+0x4cc/0x7e2
Mar 21 12:00:43.141665 (XEN)    [<ffff82d040240728>] F do_domctl+0x1850/0x192d
Mar 21 12:00:43.141699 (XEN)    [<ffff82d04031a96a>] F pv_hypercall+0x617/0x6b5
Mar 21 12:00:43.153656 (XEN)    [<ffff82d0402012ca>] F lstar_enter+0x13a/0x140
Mar 21 12:00:43.153689 (XEN)
Mar 21 12:00:43.153711 (XEN)
Mar 21 12:00:43.153731 (XEN) ****************************************
Mar 21 12:00:43.165647 (XEN) Panic on CPU 12:
Mar 21 12:00:43.165678 (XEN) Xen BUG at common/page_alloc.c:1033
Mar 21 12:00:43.165703 (XEN) ****************************************
Mar 21 12:00:43.177633 (XEN)
Mar 21 12:00:43.177662 (XEN) Manual reset required ('noreboot' specified)

This reverts commit 75214d5e53.

Signed-off-by: Julien Grall <jgrall@amazon.com>
 2024-03-21 16:02:25 +00:00
Andrew Cooper ee973396f0 x86/cpuid: More AMD features 
All of these are informational and require no further logic changes in Xen to
support.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-21 11:38:03 +00:00
Andrew Cooper 5205bda5f1 x86/p2m: Coding style cleanup 
No functional change.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
 2024-03-21 11:38:02 +00:00
Shawn Anastasio 97b90f9bf2 xen/ppc: Ensure ELF sections' physical load addresses start at 0x0 
Some boot mechanisms, including the new linux file_load kexec systemcall
used by system firmware v2.10 on RaptorCS systems will try to honor the
physical address field of the ELF LOAD section header, which will fail
when the address is based off of XEN_VIRT_START (0xc000000000000000).

To ensure that the physical address of the LOAD section header starts at
0x0, move x86's DECL_SECTION macro to xen.lds.h and use it to declare
all sections.

Signed-off-by: Shawn Anastasio <sanastasio@raptorengineering.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
 2024-03-21 09:49:20 +01:00
Jan Beulich 10e8d824b7 AMD/IOMMU: drop remaining guest-IOMMU bits too 
With a02174c6c8 ("amd/iommu: clean up unused guest iommu related
functions") having removed the sole place where d->g_iommu would be set
to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
latest from its 2nd if(). With it dropped, all other stuff in the file
is unused, too. Delete iommu_guest.c altogether.

Further delete struct guest{_buffer,_dev_table,_iommu{,_msi}} as well as
struct mmio_reg for being unused with the unused g_iommu also dropped
from struct arch_iommu.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
 2024-03-21 09:48:49 +01:00
Jan Beulich cc950c49ae x86/PoD: tie together P2M update and increment of entry count 
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of moving the increment ahead (and adjust back upon failure),
extend the PoD-locked region.

Fixes: 99af3cd40b ("x86/mm: Rework locking in the PoD layer")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: George Dunlap <george.dunlap@cloud.com>
 2024-03-21 09:48:10 +01:00
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