64-bit BAR memory address is truncated when removing a passthrough
pci device from guest since it uses "unsigned int".
So, change to use 64-bit type to fix this problem.
This is XSA-476 / CVE-2025-58149.
Fixes: b0a1af6167 ("libxenlight: implement pci passthrough")
Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit 421432b822)
Commit 53859596c0 depends on the behavioral change introduced in
ee2eb6849d that inverted the initialization of the MSI-X and header vPCI
handlers. 53859596c0 requires the header to be initialized before MSI-X.
Change the order of initialization and adjust init_msix() to carve holes
for the MSI-X tables if necessary, since it will now run after the BARs
have been possibly mapped into the domain p2m.
Fixes: f9aea52a97 ("vpci/msix: improve handling of bogus MSI-X capabilities")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Callers can pass in a vpmask which exceeds d->max_vcpus. Prevent out-of-bound
reads of d->vcpu[].
This is XSA-475 / CVE-2025-58148.
Fixes: 728acba1ba ("viridian: use hypercall_vpmask in hvcall_ipi()")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: cc64c24502
master date: 2025-10-21 14:10:13 +0200
Callers can pass vp/mask values which exceed the size of vpmask->mask. Ensure
we only set bits which are within bounds.
This is XSA-475 / CVE-2025-58147.
Fixes: b4124682db ("viridian: add ExProcessorMasks variants of the flush hypercalls")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 36e90c4ef1
master date: 2025-10-21 14:09:37 +0200
When the fixes commit re-arranged the code, it made edd=off jump to the
mbr code instead of returning from the function. Previously edd_done
was immediately before ret and skipped the MBR check.
Replace edd_done with .Ledd_mbr_sig for the start of the MBR checking,
and replace .Ledd_mbr_sig_skip with .Ledd_done to exit from the function.
edd=off jumps to .Ledd_done to return from the function, and internal
jumps go to .Ledd_mbr_sig to check edd=skipmbr.
Fixes: 5ec164fd61 ("x86/boot: re-arrange how/when we do disk I/O")
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 02e656f7c8
master date: 2025-10-16 10:25:27 +0200
The function returning zero is an error indication; we shouldn't try to
map MFN 0 and then treat that page as a context table.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: ef5b718cf8
master date: 2025-10-13 16:50:01 +0200
The variable can be cleared (set to false) by a non-init function's error
path (hwp_init_msrs()).
Fixes: 99c4570f82 ("cpufreq: Add Hardware P-State (HWP) driver")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
master commit: 4676e09b3c
master date: 2025-10-13 10:41:35 +0200
I've had the luck to come across a PCI card that exposes a MSI-X capability
where the BIR of the vector and PBA tables points at a BAR that has 0 size.
This doesn't play nice with the code in vpci_make_msix_hole(), as it would
still use the address of such empty BAR (0) and attempt to carve a hole in
the p2m. This leads to errors like the one below being reported by Xen:
d0v0 0000:22:00.0: existing mapping (mfn: 181c4300 type: 0) at 0 clobbers MSIX MMIO area
And the device left unable to enable memory decoding due to the failure
reported by vpci_make_msix_hole().
Introduce checking in init_msix() to ensure the BARs containing the MSI-X
tables are usable. This requires checking that the BIR points to a
non-empty BAR, and the offset and size of the MSI-X tables can fit in the
target BAR.
This fixes booting PVH dom0 on Supermicro AS -2126HS-TN servers with AMD
EPYC 9965 processors. The broken device is:
22:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 93)
There are multiple of those integrated controllers in the system, all
broken in the same way.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
master commit: 53859596c0
master date: 2025-10-10 11:02:39 +0200
Reading from the E9 port if the emergency console is active should return
0xe9 according to the documentation from Bochs:
https://bochs.sourceforge.io/doc/docbook/user/bochsrc.html
See `port_e9_hack` section description.
Fix Xen so it also returns the port address. OSes can use it to detect
whether the emergency console is available or not.
Fixes: d1bd157fbc ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: db5a3c31a6
master date: 2025-10-02 18:05:50 +0200
Otherwise the check for the SS feature in
check_memory_type_self_snoop_errata() fails unconditionally, which leads to
X86_FEATURE_XEN_SELFSNOOP never being set.
We could also avoid this by not doing the reset_cpuinfo() for the BSP in
identify_cpu(), because SS detection uses boot_cpu_data. However that
creates an imbalance on the state of the BSP versus the APs in the
identify_cpu() code.
I've opted for the less controversial solution of populating FEATURESET_1d
in generic_identify(), as the value is already there. The same is done for
the AMD faulting probe code. While there also populate the FEATURESET_1c
element, as the value is in context.
Fixes: f2663ca2e5 ("x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 382dd0d166
master date: 2025-09-25 16:07:05 +0200
PVH guests have no DM, so this causes the guest to fetch the online CPU
bitmap from an unbacked 0xaf00 PIO port when executing the GPE handler.
Seeing how ACPI CPU hotplug is the only event delivered via GPE, remove
the GPE handler in addition to anything ACPI CPU hotplug related.
This shrinks PVH's DSDT substantially and prevents spuriously executing
a large amount of AML with no purpose at all.
Fixes: 062975dc9441("acpi: PVH guests need _E02 method")
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: b59e564aa0
master date: 2025-09-25 09:18:55 +0200
In mca_cap_init function,the mcabanks_alloc allocates and
initializes an mca_banks structure for managing MCA banks,
setting up a bank map and storing the specified or default number
of banks.
After this we will call mcabanks_set(i, mca_allbanks);
The mcabanks_set function sets a specific bit in the bank_map of
an mca_banks structure, provided the structure, its bank_map, and
the bit index are valid.
At the end, we will call
mcabanks_free(xchg(&mca_allbanks, all));
This function is thread safe and does below:
1. Atomically exchanges the value of "mca_allbanks" with "all"
2. Returns the old value that was previously in "mca_allbanks"
So, when we will call mcabanks_free , that will free the memory.
The problem is that mcabanks_set(i, mca_allbanks) function is updating
mca_allbanks which will be freed via mcabanks_free later. This means
new mca_allbanks instance("all") will never get chance to update
it's bank_map.
Due to this when we will collect log from mcheck_mca_logout function ,
the condition "if ( !mcabanks_test(i, bankmask) )" will always fails
and MCA logs will not be collected for any bank.
The fix is to solve this problem.
Fixes: 560cf418c8 ("x86/mcheck: allow varying bank counts per CPU")
Signed-off-by: Soham Dandapat <soham.dandapat@amd.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 532988dccc
master date: 2025-09-09 08:18:11 +0200
When building Xen with GCC 12 with UBSAN and PVH_GUEST both enabled the
compiler emits the following errors:
arch/x86/setup.c: In function '__start_xen':
arch/x86/setup.c:1504:19: error: 'consider_modules' reading 40 bytes from a region of size 4 [-Werror=stringop-overread]
1504 | end = consider_modules(s, e, reloc_size + mask,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1505 | bi->mods, bi->nr_modules, -1);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/setup.c:1504:19: note: referencing argument 4 of type 'const struct boot_module[0]'
arch/x86/setup.c:686:24: note: in a call to function 'consider_modules'
686 | static uint64_t __init consider_modules(
| ^~~~~~~~~~~~~~~~
arch/x86/setup.c:1535:19: error: 'consider_modules' reading 40 bytes from a region of size 4 [-Werror=stringop-overread]
1535 | end = consider_modules(s, e, size, bi->mods,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1536 | bi->nr_modules + relocated, j);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/x86/setup.c:1535:19: note: referencing argument 4 of type 'const struct boot_module[0]'
arch/x86/setup.c:686:24: note: in a call to function 'consider_modules'
686 | static uint64_t __init consider_modules(
| ^~~~~~~~~~~~~~~~
This seems to be the result of some function manipulation done by UBSAN
triggering GCC stringops related errors. Placate the errors by declaring
the function parameter as `const struct *boot_module` instead of `const
struct boot_module[]`.
Note that GCC 13 seems to be fixed, and doesn't trigger the error when
using `[]`.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 932898d449
master date: 2025-03-17 13:33:28 +0100
We have a mix of root and non-root containers, and are trying to become
rootless. This can cause the local CPIO fragements to end up being user:user
in the test environment.
Nothing seems to go wrong so far, but it's a trap waiting to happen.
Make everything consistently root for the initrds, irrespective of the
rootness of the container the test is running in.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Denis Mukhin <dmukhin@ford.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit e3042c9fc2)
In order to safely acquire a reference for a foreign page mapping, the
P2M lock needs to be held until we have the reference in hand (or
getting one failed). Otherwise the page can change P2M type and
ownership in between.
This is CVE-2025-58145 / part of XSA-473.
Fixes: 9486a8d07b ("xen/arm: Handle remove foreign mapping")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
master commit: 2275bf83a1
master date: 2025-09-09 14:12:57 +0200
I can't see what would make the 1st of the assertions safe: For example,
the P2M lock not being held, the foreign page may disappear before we
get to call page_get_owner_and_reference(), which hence may return NULL.
Even the 2nd, which appears to be safe safe, is lacking proper release
build fallbacks.
Drop the former in favor of an if(), and convert the latter to the
equivalent of what x86 uses: ASSERT_UNREACHABLE() plus putting of the
obtained page.
This is CVE-2025-58144 / part of XSA-473.
Fixes: 9486a8d07b ("xen/arm: Handle remove foreign mapping")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Julien Grall <jgrall@amazon.com>
master commit: c5a6dd6850
master date: 2025-09-09 14:12:13 +0200
The reference TSC page is shared between all vCPUs, and the data stored in
the domain struct. However the handlers to set and clear it are not safe
against concurrent accesses. It's possible for two (or more) vCPUs to call
HV_X64_MSR_REFERENCE_TSC at the same time and cause the in-use reference
TSC page to be freed, while still being on the p2m. This creates a use-
after-free bug, where the page can end up mapped in another domain or used
by Xen while still being part of the original domain's p2m.
It's also possible to underflow the reference counter, as multiple
concurrent writes to HV_X64_MSR_REFERENCE_TSC can create an imbalance on
the number of put_page_and_type() calls.
Introduce a lock to protect the reference TSC domain field, thus
serializing concurrent vCPU accesses.
This is CVE-2025-58143 / part of XSA-472.
Fixes: 386b336522 ('viridian: use viridian_map/unmap_guest_page() for reference tsc page')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 45729a510a
master date: 2025-09-09 14:12:00 +0200
The function is called unconditionally, regardless of whether the SIM page
is mapped. Avoid a NULL pointer dereference in
viridian_synic_deliver_timer_msg() by checking whether the SIM page is
mapped.
This is CVE-2025-58142 / part of XSA-472.
Fixes: 26fba3c855 ('viridian: add implementation of synthetic timers')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 3a7b4f2897
master date: 2025-09-09 14:11:34 +0200
The function is only called when the MSR has the enabled bit set, but even
then the page might not be mapped because the guest provided gfn is not
suitable.
Prevent a NULL pointer dereference in update_reference_tsc() by checking
whether the page is mapped.
This is CVE-2025-27466 / part of XSA-472.
Fixes: 386b336522 ('viridian: use viridian_map/unmap_guest_page() for reference tsc page')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 5776a2e9db
master date: 2025-09-09 14:11:09 +0200
Jan reports the following exception when using the cycle debugging:
Feature IBRSB, seen [IBRSB, STIBP, INTEL_PSFD, EIBRS, IPRED_CTRL, RRSBA_CTRL, RRSBA, BHI_CTRL], to_process [SSBD]
Traceback (most recent call last):
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 594, in <module>
sys.exit(main())
^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 588, in main
crunch_numbers(state)
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 366, in crunch_numbers
(state.names[feat], repl(seen), repl(to_process)))
^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in repl
return "[" + ", ".join((state.names[x] for x in l)) + "]"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/local/xen.git/xen/../xen/tools/gen-cpuid.py", line 364, in <genexpr>
return "[" + ", ".join((state.names[x] for x in l)) + "]"
~~~~~~~~~~~^^^
KeyError: 534
make[2]: *** [/local/xen.git/xen/include/xen/lib/x86/Makefile:9: cpuid-autogen.h] Error 1
This is caused by commit ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature
names") being rather lazy and marking dependenices on unknown features.
Introduce a helper to pick the known features in a range, and use it for
ARCH_CAPS.
Additionally, remove trailing whitespace and an unnecessary line continuation
from the debug print.
Reported-by: Jan Beulich <jbeulich@suse.com>
Fixes: ce8c930851 ("x86/cpu-policy: MSR_ARCH_CAPS feature names")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 5edb4ccff6
master date: 2025-09-01 19:54:21 +0100
With the processing done linearly (rather than recursively), checking
whether any of the features was previously seen is wrong: That would
e.g. trigger for this simple set of dependencies
X: [A, B]
A: [C]
B: [C]
(observed in reality when making AMX-AVX512 dependent upon both
AMX-TILE and AVX512F, causing XSAVE to see AMX-AVX512 twice in its list
of dependents). But checking the whole accumulated set also isn't
necessary - just checking the feature we're processing dependents of is
sufficient. We may detect a cycle later that way, but we still will
detect it. What we need to avoid is adding a feature again when we've
already seen it.
As a result, seeding "seen[]" with "feat" isn't necessary anymore.
Fixes: fe4408d180 ("xen/x86: Generate deep dependencies of features")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 3999ff0d30
master date: 2025-09-01 13:07:53 +0200
EFI code path split options from EFI LoadOptions fields in 2
pieces, first EFI options, second Xen options.
"get_argv" function is called first to get the number of arguments
in the LoadOptions, second, after allocating enough space, to
fill some "argc"/"argv" variable. However the first parsing could
be different from second as second is able to detect "--" argument
separator. So it was possible that "argc" was bigger than the
initialized portion of "argv" array, leading to potential
uninitialized pointer dereference, in particular a string like
"-- a b c" would lead to crashes.
Using EFI shell is possible to pass any kind of string in
LoadOptions.
Fixes: bf6501a62e ("x86-64: EFI boot code")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
master commit: 375f0dd538
master date: 2025-09-01 13:07:01 +0200
SMBIOS specification dictates that tables should have a minimal length.
This commit introduces further validation for user-input SMBIOS tables.
As per SMBIOS Reference Specification:
* Type 0: For version 2.3 and later implementations, the length is at least 14h
* Type 1: 1Bh for 2.4 and later
* Type 2: at least 08h
* Type 3: 0Dh for version 2.1 and later
* Type 11: 5h (+ strings)
* Type 22: 1Ah (+ strings)
* Type 39: a minimum of 10h
Notably, this also fixes previously incorrect check for chassis handle in
smbios_type_2_init. Chassis handle is a WORD, therefore, the condition now
correctly checks for >= 13 instead of > 13.
hvmloader currently implements version 2.4
Furthermore, this commit introduces smbios_pt_copy helper function to substitute
previously repeating pattern of locating the struct in physical memory (via
get_smbios_pt_struct), checking the length and copying it into SMBIOS region.
Fixes: 4d23036e70 ("HVM firmware passthrough SMBIOS processing")
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 2f7d52f016
master date: 2025-08-27 11:26:33 +0200
* `sizeof_field` returns the size of a specific struct member
* `endof_field` returns the offset to the end of the member within the struct
It will be useful in upcoming layout checks of SMBIOS structs.
Signed-off-by: Petr Beneš <w1benny@gmail.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
master commit: 17e66ca918
master date: 2025-08-27 11:26:33 +0200
The current code to restore the timer state on resume is incomplete. While
the local APIC Initial Count Register is saved and restored across
suspension (even if possibly no longer accurate since it's not adjusted to
account for the time spent in suspension), the TSC deadline MSR is not
saved and restored, hence hosts using the TSC deadline timer will likely
get stuck when resuming from suspension.
The lack of restoring of the TSC deadline MSR was mitigated by the raising
of a timer softirq in mwait_idle_with_hints() if the timer had expired,
previous to commit 3faf0866a3, which removed
that logic.
This patch fixes the usage of the TSC deadline timer with suspension, by
unconditionally raising a timer softirq on resume, that will take care of
rearming the hardware timer. Given that a timer softirq will be
unconditionally risen, there's no need to save and restore the APIC Initial
Count Register anymore either.
Note that secondary processors don't need this special treatment when
resuming, since they are offlined before suspension and brought back up
during resume, the first timer that gets setup will trigger a timer softirq
unconditionally, for example from sched_migrate_timers() that gets called
for each secondary processor.
Link: https://github.com/QubesOS/qubes-issues/issues/10110
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Fixes: fd1291a826 ('X86: Prefer TSC-deadline timer in Xen')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
master commit: 757abedabb
master date: 2025-08-27 09:33:12 +0200
There's no family check gating intel_init_ppin(), making it incorrect to
use on non Fam6 CPUs.
Emerald Rapids is the final CPU to have PPIN but lack the architectural
enumeration, so include it too.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 49e6eb744e
master date: 2025-08-25 14:04:41 +0100
Otherwise the PCI accesses to segments different than the first one done by
the IOMMU initialization code would silently fail by returning all ones.
Introduce a new helper, called pci_setup(), and move both the creation of
PCI segment 0 internal data structures, plus the parsing of ACPI MMCFG
table to it. This moves acpi_mmcfg_init() slightly earlier from
acpi_boot_init() into pci_setup().
Note that further work will be needed to support systems where access
methods to segments different than 0 is not discoverable by Xen.
Fixes: 3950f2485b ('x86/x2APIC: defer probe until after IOMMU ACPI table parsing')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: c292772b49
master date: 2025-08-21 11:57:25 +0200
Fix the incorrect condition that causes hvm_alloc_legacy_ioreq_gfn()
to return INVALID_GFN even if the HVM param was installed properly by
the toolstack.
Fixes: 3486f398a3 (' x86/hvm/ioreq: allow ioreq servers to use HVM_PARAM_[BUF]IOREQ_PFN')
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 282ed258a5
master date: 2025-08-18 10:43:52 +0200
In order to legitimately set up initial mappings past _end[], we need
to make sure that the entire mapped range is inside a RAM region.
Therefore we need to inform the bootloader (or alike) that our allocated
size is larger than just the next SECTION_ALIGN-ed boundary past _end[].
This allows dropping a command line option from the tool, which was
introduced to work around a supposed linker bug, when the problem was
really Xen's.
While adjusting adjacent code, correct the argc check to also cover the
case correctly when --notes was passed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 4fb075201f
master date: 2025-08-18 10:42:24 +0200
If the config file is builtin, cfg.addr will be zero but Xen
unconditionally calls FreePages() on the address.
Xen may also call FreePages() with a zero address if blexit() is called
after this point since cfg.need_to_free is not set to false.
The UEFI specification does not say whether calling FreePages() with a
zero address is allowed so let's be cautious and use cfg.need_to_free
properly.
Fixes: 8a71d50ed4 ("efi: Enable booting unified hypervisor/kernel/initrd images")
Fixes: 04be2c3a06 ("efi/boot.c: add file.need_to_free")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by Daniel P. Smith <dpsmith@apertussolutions.com>
master commit: 7fddedd530
master date: 2025-08-12 11:40:28 +0200
The current logic in the HPET interrupt ->ack() hook will perform a local
APIC EOI ahead of enabling interrupts, possibly leading to recursion in the
interrupt handler.
Fix this by doing the local APIC EOI strictly after the window with
interrupt enabled, as that prevents the recursion, and would only allow for
interrupts with higher priority to be serviced.
Use the generic ack_nonmaskable_msi_irq() and end_nonmaskable_irq()
functions, removing the need for hpet_msi_ack().
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Fixes: 3ba523ff95 ('CPUIDLE: enable MSI capable HPET for timer broadcast')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 1db7829e56
master date: 2025-08-06 10:47:16 +0200
SYMBOL_NAME_SIZE is 124, not 128. Use the symbolic name there as well,
to avoid any disconnect.
While there correct indentation on the following line as well.
Coverity ID: 1659391
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
master commit: dfabb3fee3
master date: 2025-07-31 14:44:02 +0200
When running xl in a domU, it doesn't have access to the Xen command
line. Before the non-truncating xc_xenver_cmdline(), it was always set
with strdup, possibly of an empty string. Now it's NULL. Treat it the
same as empty cmdline, as it was before. Autoballoon isn't relevant for
xl devd in a domU anyway.
Fixes: 75f9160762 ("tools: Introduce a non-truncating xc_xenver_cmdline()")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
master commit: a4988c4177
master date: 2025-07-31 14:44:02 +0200
ARINC653 specification requires partition scheduling to be deterministic
and periodic over time.
However, the use of current timestamp (now) as the baseline to calculate
next_major_frame and next_switch_time introduces a delay in the start of
major frame at every period, which breaks determinism and periodicity in
partition scheduling.
For example, we observe 3.5 msec of accumulated delay at the 21st major
frame with the following configuration.
Target : qemuarm64
xen version : 4.19 (43aeacff86, x86/IRQ: constrain creator-domain-ID assertion)
dom1 : 10 msec runtime
dom2 : 10 msec runtime
$ a653_sched -p Pool-arinc dom1:10 dom2:10
0.014553536 ---x d?v? runstate_change d1v0 runnable->running //1st major
frame
0.034629712 ---x d?v? runstate_change d1v0 runnable->running //2nd major
frame
<snip>
0.397747008 |||x d?v? runstate_change d1v0 runnable->running //20th
major frame
0.418066096 -||x d?v? runstate_change d1v0 runnable->running //21st
major frame
This is due to an inherent delta between the time value the scheduler timer
is programmed to be fired with and the time value the schedule function
is executed.
Another observation that breaks the deterministic behavior of partition
scheduling is a delayed execution of schedule(); It was called 14 msec
later than programmed.
1.530603952 ---x d?v? runstate_change d1v0 runnable->running
1.564956784 --|x d?v? runstate_change d1v0 runnable->running
Enforce the periodic behavior of partition scheduling by using the value
next_major_frame as the base to calculate the start of major frame and
the next domain switch time.
Per discussion with Nathan Studer, there are odd cases the first minor
frame can be also missed. In that scenario, iterate through the schedule
after resyncing the expected next major frame.
Per suggestion from Stewart Hildebrand, use a modulo operation to
calculate the start of next major frame.
Fixes: 22787f2e10 ("ARINC 653 scheduler")
Suggested-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Suggested-by: Nathan Studer <nathan.studer@dornerworks.com>
Signed-off-by: Anderson Choi <anderson.choi@boeing.com>
Reviewed-by: Stewart Hildebrand <stewart@stew.dk>
master commit: f2927d8343
master date: 2025-07-28 13:05:56 +0200
When a running unit is about to be scheduled out due to a competing unit
with the highest remaining credit, the residual credit of the previous
unit is currently ignored in csched2_runtime() because it hasn't yet
been reinserted into the runqueue.
As a result, two equally weighted, busy units can often each be granted
almost the maximum possible runtime (i.e. consuming CSCHED2_CREDIT_INIT
in one shot) when only those two are active. In broad strokes two units
switch back and forth every 10ms (CSCHED2_MAX_TIMER). In contrast, when
more than two busy units are competing, such coarse runtime allocations
are rarely seen, since at least one active unit remains in the runqueue.
To ensure consistent behavior, have csched2_runtime() take into account
the previous unit's latest credit when it still can/wants to run.
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Reviewed-by: Juergen Gross <jgross@suse.com>
master commit: ae648e9f80
master date: 2025-07-28 13:04:40 +0200
Xen currently uses an ASID scheme where:
- ASIDs are cycled where a "TLB flush" is performed
- When ASIDs wrap around, perform a full TLB flush
- In exceptional cases, stop using ASIDs
However, the TLB control mode used only flushes the current active ASID of
the logical processor. Which mean that will supply "stale" ASIDs (not flushed),
because it hasn't been actually flushed (TLB_CTRL_FLUSH_ASID only performs a
TLB flush of the ASID set in VMCB).
This affects CPUs where flush-by-asid is available (Fam15h (2011) and later).
To fix this, always flush all ASIDs even when flush-by-asid is available.
Fixes: 64b1da5a2f ("x86/svm: Use flush-by-asid when available")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 68871b1f9b
master date: 2025-07-23 15:23:44 +0200
While supposedly safe via enforcing a control flow change when modifying
already prefetched code, it may not really be. Afaik a request is
pending to drop the first of the two options in the SDM's "Handling
Self- and Cross-Modifying Code" section (still present there as of
version 087). Insert a serializing instruction there, and remove the
"noinline" in exchange.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
master commit: c5b06d0b1b
master date: 2025-07-23 15:17:28 +0200
smp_store_cpu_info() doesn't call identify_cpu() again during S3 resume,
hence it is wrong to zap APs' data while bringing them down (and we're
not just parking them there) during suspend.
Fixes: bb502a8ca5 ("x86: check feature flags after resume")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
master commit: 55719030b0
master date: 2025-07-17 17:55:54 +0200
NEHALEM_EX is affected by the erratum too.
Change the comment to be the full erratum text, not an interpretation of it.
Fixes: 95807bcae4 ("C6 state with EOI issue fix for some Intel processors")
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: d225205a0b
master date: 2025-07-18 13:40:12 +0100
The current p2m type-change loop in ept_vcpu_flush_pml_buffer() relies on
each call to p2m_change_type_one() taking the p2m lock, doing the change
and then dropping the lock and flushing the p2m. Instead take the p2m lock
outside of the loop, so that calls to gfn_{,un}lock() inside
p2m_change_type_one() just take the p2m lock recursively, and more
importantly, the flush is deferred until the p2m is unlocked in
ept_vcpu_flush_pml_buffer().
No functional change intended in the end result of
ept_vcpu_flush_pml_buffer(), however a possibly noticeable performance
improvement is expected.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 060e9ab6e4
master date: 2025-07-18 09:17:25 +0200
smp_store_cpu_info() doesn't call identify_cpu() again during S3 resume,
hence it is wrong to overwrite APs' data using boot_cpu_data. With
7126b7f806 ("x86/CPU: re-work populating of cpu_data[]") this now
results in a crash, as the cpu_to_socket() use in smp_store_cpu_info()
then obtains a bad socket number, much like was already observed in [1].
[1] https://lists.xen.org/archives/html/xen-devel/2025-06/msg01879.html
Fixes: bb502a8ca5 ("x86: check feature flags after resume")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: acaa69d985
master date: 2025-07-17 12:49:18 +0200
Before CPU identification has run (and it may not have run at all e.g.
when AP bringup failed altogether), cpu_data[].phys_proc_id (which is
what cpu_to_socket() resolves to) can't really be used. The use of
cpu_to_socket()'s result as an array index in cpu_smpboot_free()
therefore needs guarding, as the function will also be invoked upon AP
bringup failure, in which case CPU identification may not have run.
Without "x86/CPU: re-work populating of cpu_data[]" [1] the issue is
less pronounced: The field starts out as zero, then has the BSP value
(likely again zero) copied into it, and it is properly invalidated only
in cpu_smpboot_free(). Still it is clearly wrong to use the BSP's socket
number here.
Making the guard work with and without the above patch applied turns out
interesting: Prior to that patch, the sole invalidation done is that in
cpu_smpboot_free(). Upon a later bringup attempt, the fields invalidated
are overwritten by the BSP values again, though. Hence compare APIC IDs,
as they cannot validly be the same once CPU identification has run.
[1] https://lists.xen.org/archives/html/xen-devel/2024-02/msg00727.html
Fixes: 4824bdfdab ("x86: add socket_cpumask")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 8c15d3d187
master date: 2025-07-17 12:47:04 +0200
SDM revision 088 points out that apparently as of quite some time ago on
Intel hardware BSF and BSR may alter all arithmetic flags, not just ZF.
Because of the inconsistency (sometimes even errata, and because
documentation doesn't look to be quite right about PF), best we can do
is simply take the flag values from what the processor produces, just
like we do for various other arithmetic insns. (Note also that AMD and
Intel have always been disagreeing on arithmetic flags other than ZF.)
To be both safe (against further anomalies) and consistent, extend this
to {L,T}ZCNT as well. (Emulating the two insns correctly even when
underlying hardware doesn't support it was perhaps nice, but yielded
guest-observable inconsistencies.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 37a55e69c7
master date: 2025-07-16 12:51:26 +0200
Clearwater Forest (CWF) SoC has the same C-states as Sierra Forest (SRF)
SoC. Add CWF support by re-using the SRF C-states table.
Note: it is expected that CWF C-states will have same or very similar
characteristics as SRF C-states (latency and target residency).
However, there is a possibility that the characteristics will end up
being different enough when the CWF platform development is finished.
In that case, a separate CWF C-states table will be created and populated
with the CWF-specific characteristics (latency and target residency).
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20241203130306.1559024-1-artem.bityutskiy@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git eeed4bfbe9b9
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 5c5bb8dab7
master date: 2025-07-09 11:02:35 +0200
Add Granite Rapids Xeon C-states, which are C1, C1E, C6, and C6P.
Comparing to previous Xeon Generations (e.g., Emerald Rapids), C6
requests end up only in core C6 state, and no package C-state promotion
takes place even if all cores in the package are in core C6.
C6P requests also end up in core C6, but if all cores have requested
C6P, the SoC will enter the package C6 state.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Link: https://patch.msgid.link/20240806160310.3719205-1-artem.bityutskiy@linux.intel.com
[ rjw: Changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 370406bf5738
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 3c7186b2a8
master date: 2025-07-09 11:02:08 +0200
Add Sierra Forest SoC C-states, which are C1, C1E, C6S, and C6SP.
Sierra Forest SoC is built with modules, each module includes 4 cores
(Crestmont microarchitecture). There is one L2 cache per module, shared
between the 4 cores.
There is no core C6 state, but there is C6S state, which has module scope:
when all 4 cores request C6S, the entire module (4 cores + L2 cache)
enters the low power state.
C6SP state has package scope - when all modules in the package enter C6S,
the package enters the power state mode.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 92813fd5b156
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: edd31f0fe9
master date: 2025-07-09 11:01:50 +0200
Add Intel Grand Ridge SoC C-states, which are C1, C1E, and C6S.
The Grand Ridge SoC is built with modules, each module includes 4 cores
(Crestmont microarchitecture). There is one L2 cache per module, shared
between the 4 cores.
There is no core C6 state, but there is C6S state, which has module
scope: when all 4 cores request C6S, the entire module (4 cores + L2
cache) enters the low power state.
Package C6 is not supported by Grand Ridge SoC.
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ac89d11b93cc
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: a514b54992
master date: 2025-07-09 11:01:34 +0200
Add intel_idle support for MeteorLake.
C1 and C1E states on Meteorlake are mutually exclusive, like Alderlake
and Raptorlake, but they have little latency difference with measureable
power difference, so always enable "C1E promotion" bit and expose C1E
only.
Expose C6 because it has less power compared with C1E, and smaller
latency compared with C8/C10.
Ignore C8 and expose C10, because C8 does not show latency advantage
compared with C10.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git eeae55ed9c0a
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 433ed7d4f8
master date: 2025-07-09 11:01:03 +0200
Jiqian Chen
Roger Pau Monné
Teddy Astie
Jason Andryuk
Jan Beulich
Alejandro Vallejo
Soham Dandapat
Andrew Cooper
Frediano Ziglio
Petr Beneš
Oleksandr Tyshchenko
Ross Lagerwall
Marek Marczykowski-Górecki
Anderson Choi
Koichiro Den
Artem Bityutskiy
Zhang Rui