We can easily avoid the risk of wrapping UINT_MAX <-> 0 by applying a
check against the compile-time-constant maximum number of colors.
Additionally the overflow checks suffered from an off-by-1, as the parsed
ranges are inclusive (e.g. end == start being possible, requiring 1 array
slot, while availability of 0 slots was checked in that case).
Fixes: 6cdea3444e ("xen/arm: add Dom0 cache coloring support")
Reported-by: Mykola Kvach <xakep.amatop@gmail.com>
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
xen/common: llc-coloring: Fix off-by-one in parse_color_config()
The check uses (*num_colors + (end - start + 1)) >= max_num_colors, which
rejects a configuration where exactly max_num_colors colors are specified.
For example, if max_num_colors is 4 and *num_colors is 0, a range "0-3"
gives (end - start + 1) = 4, and (0 + 4) >= 4 is true, incorrectly
returning -EINVAL.
Fix this by switching the overflow condition to the state before commit
cba8a584de that regressed the behavior (i.e. don't add 1).
Fixes: cba8a584de ("llc-coloring: improve checking while parsing")
Signed-off-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
master commit: cba8a584de
master date: 2026-04-07 13:52:44 +0200
master commit: dc28f531e6
master date: 2026-04-10 12:14:05 +0200
The message emitted by pre_parse() pretty clearly states the original
intention. Yet what it said wasn't done, and would have been unfriendly to
the user. Hence accesses past the allocated buffer were possible. Insert a
terminating NUL immediately past the data read, to then drop the no longer
applicable message.
NB: The iscntrl() check of just the last byte is more strict than what
pre_parse() would accept without issuing its prior message, yet I'd like
to keep the new logic reasonably simple. Config files shouldn't be huge,
and we shouldn't be _that_ short of memory (or we'd fail elsewhere pretty
soon).
Fixes: bf6501a62e ("x86-64: EFI boot code")
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
master commit: df75f77092
master date: 2026-04-07 08:59:15 +0200
Right now, xstate_alloc_save_area() leaves both XSTATE_BV and FTW clear. This
causes a difference in behaviour between FXRSTOR and XRSTOR.
Switch to using using XSTATE's idea of initial configuration which will behave
the same even on pre-XSAVE hardware. Expand the comment to explain why.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 639de2aafa
master date: 2026-03-30 15:48:13 +0100
Read the existing PCI command register and only add the required bits to
it, as to avoid clearing bits that might be possibly set by the firmware
already, which might put the device into a non-working state.
Xen being the owner of the PCI device it's legitimately allowed to change
command registers bits. Be careful however in case buggy devices require
certain command register bits to be enabled, while not strictly required
from Xen's usage.
Fixes: f2ff5d6628 ("ns16550: enable PCI serial card usage")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: ebf5439725
master date: 2026-03-30 16:43:14 +0200
Auto-discovered serial PCI devices when using dev=amt|pci won't get
->ps_bdf_enable, and as such some of the logic (like making sure the
respective BARs are enabled) won't be applied to them.
Fix by unconditionally setting ->ps_bdf_enable for all PCI serial devices,
and removing the special case that was done in some places by checking
whether the ->bar was set. This also allows simplifying the logic in
pci_serial_early_init().
Fixes: 9738db88f6 ("xen: Automatically find serial port on PCI/PCIe and AMT devices.")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 4bf3336062
master date: 2026-03-30 16:43:14 +0200
Commit 19ab8356ab ("tools: remove support for running a guest with
qemu-traditional") made passing --dm_version to mk_dsdt mandatory on
x86 but didn't fix all the invocations of it.
The previous default was qemu-xen-traditional so with that removed set
the dm_version to qemu-xen for this invocation.
Without this change, Xen fails to build on x86 when using
--enable-rombios.
Fixes: 19ab8356ab ("tools: remove support for running a guest with qemu-traditional")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: ea12f9d257
master date: 2026-03-27 18:56:42 +0000
When using key pairs for the uart configuration (com1 and com2 command line
options), report an error if the passed device=<type> is not recognized
instead of silently ignoring it.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 550ee7c198
master date: 2026-03-27 14:52:40 +0100
By initializing major_frame in a653sched_init(), an idle period was
inadvertently introduced into the default schedule. Account for the
initial value of major_frame when populating the default schedule.
Fixes: f2927d8343 ("xen/arinc653: fix delay in the start of major frame")
Signed-off-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
master commit: 6d412c0599
master date: 2026-03-26 10:49:11 +0100
Incrementing ->sched_index between bounds check and array access may
result in accessing one past the array when that is fully filled
(->num_schedule_entries == ARINC653_MAX_DOMAINS_PER_SCHEDULE).
Fixes: 22787f2e10 ("ARINC 653 scheduler")
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stewart Hildebrand <stewart@stew.dk>
master commit: 5a1121633f
master date: 2026-03-26 10:47:41 +0100
When that code still lived in a653sched_init(), it was redundant with the
earlier memset() / xzalloc(). Once moved, the full structure field needs
setting, as dom_handle_cmp() uses memcmp() and arinc653_sched_set() may
have clobbered entries. Rather than implying the handle to be all zero,
copy the handle out of the domain structure.
Fixes: 9f0c658bae ("arinc: add cpu-pool support to scheduler")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Stewart Hildebrand <stewart@stew.dk>
master commit: 2a0ee29f5e
master date: 2026-03-26 10:47:08 +0100
MCE init for APs was broken when CPU feature re-checking was added. At the
same time make sure we don't bypass setup_doitm() (and whatever else may
be added to the bottom of identify_cpu()).
Fixes: bb502a8ca5 ("x86: check feature flags after resume")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 5ebd4dd141
master date: 2026-03-24 12:05:42 +0100
Most (if not all) Intel CPUs starting from Sandy Bridge have up to 8
event selectors per core, which could be halved per hyperthread.
However, current PV emulation logic doesn't support up to 8 event selector,
leading to errors when trying to access them, hence, preventing Linux from
driving the vPMU correctly.
Make sure up to MSR_P6_EVNTSEL(7) is usable, which is the same upper bound as
used in VMX code.
The check if the event selector actually exist for the hardware is done in
core2_vpmu_do_{rdmsr,wrmsr}, hence we're not allowing to access non-existent
MSRs.
Fixes: 27c5541986 ("x86/VPMU: add support for PMU register handling on PV guests")
Signed-off-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 4e9d9e7cc9
master date: 2026-03-24 12:04:46 +0100
Hans reports that Xen no longer builds on Debian unstable/sid:
Assembler messages:
{standard input}:474: Error: unknown or missing system register name at operand 1 -- `msr TEECR32_EL1,x0'
{standard input}:480: Error: unknown or missing system register name at operand 1 -- `msr TEEHBR32_EL1,x0'
{standard input}:488: Error: unknown or missing system register name at operand 2 -- `mrs x0,TEECR32_EL1'
{standard input}:494: Error: unknown or missing system register name at operand 2 -- `mrs x0,TEEHBR32_EL1'
make[5]: *** [Rules.mk:249: arch/arm/domain.o] Error 1
This turns out to be an intentional change in binutils. ThumbEE was dropped
ahead of ARM v8 (i.e. AArch64).
Xen supports ARM v7+virt extensions so in principle we could #ifdef
CONFIG_ARM_32 to keep it working. However, there was apparently no use of
ThumbEE outside of demo code, so simply drop it.
On ThumbEE capable hardware, unconditionally trap ThumbEE instructions, and
drop the context switching logic for TEE{CR,HBR}32.
Reported-by: Hans van Kranenburg <hans@knorrie.org>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
xen/arm: Set ThumbEE as not present in PFR0
Force ThumbEE support to not available in the version of the PFR0
register value we present to guest.
Xen does not support ThumbEE and will trap all access to ThumbEE
registers so do not report it being supported if the hardware supports
it.
Fixes: 5bbe1fe413 ("ARM: Drop ThumbEE support")
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Michal Orzel <michal.orzel@amd.com>
Reviewed-by: Luca Fancellu <luca.fancellu@arm.com>
Tested-by: Luca Fancellu <luca.fancellu@arm.com>
master commit: 5bbe1fe413
master date: 2025-12-05 18:06:19 +0000
master commit: 1ecb5946bd
master date: 2026-01-05 10:33:03 +0000
This reverts commit b304f94842 and its
prereq 7e10bb1501 ("xen/mm: remove
aliasing of PGC_need_scrub over PGC_allocated"). Further fixes are
needed before this can be considered for backporting.
Family 0x1a covers both Zen5 and Zen6, but the latter is not believed to be
vulnerable to entrysign.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit bd15fdedaf)
The setting of errno in canonicalize() is rather fragile and seems to
be even wrong in one corner case: when the invalid path "/local/domain/"
is passed, sscanf() will set errno to 0, resulting in canonicalize() to
return NULL with errno being 0. This can result in triggering the
assert(conn->in == NULL) in consider_message().
Don't assume the initial setting of errno to "EINVAL" will stay valid
in all cases and set it to EINVAL only when returning NULL due to an
invalid path.
This is XSA-481/CVE-2026-23555
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Julien Grall <julien@xen.org>
(cherry picked from commit 4c61822b04)
In the EPT implementation, the defer flushing logic is used
unconditionally, and that would lead to paging memory being returned to the
paging pool before its references had been flushed.
Issue any pending flushes before freeing the paging memory back to the
pool.
Note AMD (NPT) and Shadow paging are not affected, as they don't implement
the deferred flushing logic.
This is XSA-480 / CVE-2026-23554
Fixes: 4a59e6bb3a ("x86/EPT: squash meaningless TLB flush")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit 4bc2e5333a)
The label used upon the function failing is wrong. Instead of correcting
the label, move the invocation up a little, to also avoid it altogether
for the idle domain (where ->vmtrace_size would be zero, and hence the
function would bail right away anyway).
Fixes: 217dd79ee2 ("xen/domain: Add vmtrace_size domain creation parameter")
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: adfbdaa347
master date: 2026-03-10 09:23:25 +0100
For INT $N instructions (besides $0x80 for which there is a dedicated fast
path), handling is mostly fault-based because of DPL0 gates in the IDT. This
means that when the guest kernel allows the instruction too, Xen must
increment %rip to the end of the instruction before passing a trap to the
guest kernel.
When an INT $N instruction has a prefix, it's longer than two bytes, and Xen
will deliver the "trap" with %rip pointing into the middle of the instruction.
Introduce a new pv_emulate_sw_interrupt() which uses x86_insn_length() to
determine the instruction length, rather than assuming two.
This is a change in behaviour for PV guests, but the prior behaviour cannot
reasonably be said to be intentional.
This change does not affect the INT $0x80 fastpath. Prefixed INT $N
instructions occur almost exclusively in test code or exploits, and INT $0x80
appears to be the only user-usable interrupt gate in contemporary PV guests.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: a934a600c4
master date: 2026-03-03 15:15:53 +0000
Multiple downstream distros have tried passing discrete CPIO archives and
tripped over this not working. It turns out to be easy to support, so do so.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Teddy Astie <teddy.astie@vates.tech>
[jb: doc change dropped as inapplicable to the older form]
master commit: 878a9cfa45
master date: 2026-03-03 15:15:53 +0000
The records reported used to contain Linux enumerators. We first broke
that connection when purging unused ones, and then again when switching to
the bit mask forms.
Fixes: 4084130511 ("x86/cpu: Drop unused X86_VENDOR_* values")
Fixes: 0cd074144c ("x86/cpu: Renumber X86_VENDOR_* to form a bitmap")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Jason Andryuk <jason.andryuk@amd.com>
master commit: a94c5fd829
master date: 2026-02-23 08:39:58 +0100
Observed when attempting to boot a >4TiB VM:
After a call to domain_setmaxmem with 6370254848 (KiB), the domain's maxmem
got set to 2075287552, which is exactly 2^32 smaller.
xc_domain_setmaxmem takes an uint64_t as a parameter, and the OCaml value
is 64-bit already, so fix the C variable to match the type and avoid the
truncation.
Fixes: f5b43e95fa ("libxl: fix "xl mem-set" regression from 0c029c4da2")
Signed-off-by: Edwin Török <edwin.torok@citrix.com>
Acked-by: Christian Lindig <christian.lindig@cloud.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit 381b4ff16f)
Alpine Linux, when using --enable-systemd to get the init files, fails with:
tools/include/xen-sd-notify.h:69:3: error: call to undeclared library
function 'memcpy' with type 'void *(void *, const void *, unsigned long)';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
69 | memcpy(socket_addr.sun.sun_path, socket_path, path_length);
| ^
This will be down to using musl rather than glibc. Include the appropriate
header.
Fixes: 78510f3a15 ("tools: Import stand-alone sd_notify() implementation from systemd")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit 8efff5a69a)
Archlinux just updated glibc to 2.43+r5+g856c426a7534-1 and that
causes libxl build failure:
libxl_cpuid.c: In function ‘libxl_cpuid_parse_config_xend’:
libxl_cpuid.c:447:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
447 | endptr = strchr(str, '=');
| ^
libxl_cpuid.c:452:16: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
452 | endptr = strchr(str, ',');
| ^
libxl_cpuid.c:454:20: error: assignment discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
454 | endptr = strchr(str, 0);
| ^
cc1: all warnings being treated as errors
Add missing consts. Note in libxl_cpuid_parse_config_xend() non-const
endptr still is needed, to be compatible with the second argument to
strtoul(). Add second variable for this reason.
And while at it, move semicolon to its own line
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit 44da0e3b4f)
QEMU used to ignore JSON types and do conversion string <-> integer
automatically for the command "device_add", but that was removed in
QEMU 9.2 (428d1789df91 ("docs/about: Belatedly document tightening of
QMP device_add checking")).
Fixes: 9718ab394d ("libxl_usb: Make libxl__device_usbctrl_add uses ev_qmp")
Fixes: 40c7eca10a ("libxl_usb: Make libxl__device_usbdev_add uses ev_qmp")
Signed-off-by: Anthony PERARD <anthony.perard@vates.tech>
Tested-by: Maximilian Engelhardt <maxi@daemonizer.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 85e12104f4)
The first parameter passed to align_timer() is the timer expiration, not
the current time. Adjust the calls to align_timer() in the on-demand
governor to pass the expected timer expiration as the first parameter.
Fixes: af74e3a15a ("cpufreq: align dbs timer for better package C state residency")
Fixes: 382b95f627 ("Fix cpufreq HW-ALL coordination handle")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: a0ed5bcfbe
master date: 2026-03-02 17:16:26 +0100
The logic in dbs_check_cpu() resets the sampling window even when the
sampling period is considered too small. This leads to further calls
finding an imbalance between the total window time and the idle time, as
the total window time is possibly shorter than the idle time.
Fix by resetting the sampling window start time in the same block where the
current idle time is stored. While there also prevent a duplicated call to
NOW() and instead re-use the previously fetched value.
Fixes: d6f001cb91 ("x86: Implement cpufreq ondemand policy")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 74867aae25
master date: 2026-03-02 17:16:26 +0100
add_one_user_rmrr() operates on inclusive [start,end] range, which means
the end page needs to be calculated as (start + page_count - 1).
This off-by-one error resulted in one extra pages being mapped in IOMMU
context, but not marked as reserved in the memory map. This in turns
confused PVH dom0 code, resulting in the following crash:
(XEN) [ 3.934848] d0: GFN 0x5475c (0x5475c,5,3) -> (0x46a0f4,0,7) not permitted (0x20)
(XEN) [ 3.969657] domain_crash called from arch/x86/mm/p2m.c:695
(XEN) [ 3.972568] Domain 0 reported crashed by domain 32767 on cpu#0:
(XEN) [ 3.975527] Hardware Dom0 crashed: rebooting machine in 5 seconds.
(XEN) [ 8.986353] Resetting with ACPI MEMORY or I/O RESET_REG.
I checked other parts of this API and it was the only error like this.
Other places:
- iommu_get_extra_reserved_device_memory() -> reserve_e820_ram() - this
function expects exclusive range, so the code is correct
- add_one_extra_ivmd() - this operates on start address and memory
length
Fixes: 2d9b369913 ("IOMMU/VT-d: wire common device reserved memory API")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: d41501fcf6
master date: 2026-02-17 08:59:34 +0100
Currently the -Wa,--noexecstack parameter is only passed to the compiler
when building assembly files, as the assembler doesn't add such note for
stack attributes.
However, the default addition of the .note.GNU-stack section is dependent
on the ELF target used. Adjust the passing of -Wa,--noexecstack so it's
added to CFLAGS instead of AFLAGS, and hence such section is also added to
object files generated from .c sources. This fixes the complains from the
linker about missing .note.GNU-stack section when building x86-64 Xen on
Darwin platforms.
Note we could instead pass `-z noexecstack` to the linker, but that however
would mask any possible errors or unintended mismatches from previous
steps.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 3dfd77003c
master date: 2026-02-13 16:42:42 +0100
BSD grep only recognizes [[:blank:]] as a valid expression when using
extended (modern) regular expressions. Pass -E to the grep call used in
efi-nr-fixups.
Additionally, the return from `wc -l` is space padded on BSD, and hence
the content of efi-nr-fixups is " 2", not plain "2". Strip the
spaces in the Makefile using $(strip ...).
Fixes: 1be65ec4c8 ('x86/EFI: avoid use of GNU ld's --disable-reloc-section when possible')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: c13335b5c1
master date: 2026-02-13 16:42:34 +0100
Fix calculating the table size - it consists of a header + entries, not
just entries.
This bug caused the last entry to have garbage in its final fields,
including LowestSupportedFwVersion and CapsuleFlags, which (usually)
made fwupd able to detect firmware update availability, but refuse
actually installing it.
Fixes: dc7da0874b ("EFI: preserve the System Resource Table for dom0")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
master commit: 3ea44aa78c
master date: 2026-02-12 11:35:05 +0100
GNU make 4.4+ exposes variable overrides in MAKEFLAGS after "--" (e.g.
O=/path, FOO=bar). The silent-mode check searches for "s" and can match
an override value, forcing silent output even without -s.
Use MFLAGS for short options and filter out any long options before
searching for "s". This preserves -s detection while avoiding false
positives from overrides.
Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: f2a31b7d7c
master date: 2026-02-10 10:22:53 +0100
Currently do_kexec_op_internal() will return 0 for unknown hypercalls. Fix
this by returning -EOPNOTSUPP instead.
While there remove the pointless initialization of ret to -EINVAL; it just
makes the code confusing.
Fixes: d046f361dc ("Xen Security Modules: XSM")
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 1ee8b11c11
master date: 2026-02-06 20:56:16 +0100
The limitation of shared_info being allocated below 4G to fit in the
start_info field only applies to 32bit PV guests. On 64bit PV guests the
start_info field is 64bits wide. HVM guests don't use start_info at all.
Drop the restriction in arch_domain_create() and instead free and
re-allocate the page from memory below 4G if needed in switch_compat(),
when the guest is set to run in 32bit PV mode.
Fixes: 3cadc0469d ("x86_64: shared_info must be allocated below 4GB as it is advertised to 32-bit guests via a 32-bit machine address field in start_info.")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 8a9255405c
master date: 2026-02-05 21:27:40 +0100
Physmap population has the need to use pages as big as possible to reduce
p2m shattering. However that triggers issues when big enough pages are not
yet scrubbed, and so scrubbing must be done at allocation time. On some
scenarios with added contention the watchdog can trigger:
Watchdog timer detects that CPU55 is stuck!
----[ Xen-4.17.5-21 x86_64 debug=n Not tainted ]----
CPU: 55
RIP: e008:[<ffff82d040204c4a>] clear_page_sse2+0x1a/0x30
RFLAGS: 0000000000000202 CONTEXT: hypervisor (d0v12)
[...]
Xen call trace:
[<ffff82d040204c4a>] R clear_page_sse2+0x1a/0x30
[<ffff82d04022a121>] S clear_domain_page+0x11/0x20
[<ffff82d04022c170>] S common/page_alloc.c#alloc_heap_pages+0x400/0x5a0
[<ffff82d04022d4a7>] S alloc_domheap_pages+0x67/0x180
[<ffff82d040226f9f>] S common/memory.c#populate_physmap+0x22f/0x3b0
[<ffff82d040228ec8>] S do_memory_op+0x728/0x1970
Introduce a mechanism to preempt page scrubbing in populate_physmap(). It
relies on stashing the dirty page in the domain struct temporarily to
preempt to guest context, so the scrubbing can resume when the domain
re-enters the hypercall. The added deferral mechanism will only be used for
domain construction, and is designed to be used with a single threaded
domain builder. If the toolstack makes concurrent calls to
XENMEM_populate_physmap for the same target domain it will trash stashed
pages, resulting in slow domain physmap population.
Note a similar issue is present in increase reservation. However that
hypercall is likely to only be used once the domain is already running and
the known implementations use 4K pages. It will be deal with in a separate
patch using a different approach, that will also take care of the
allocation in populate_physmap() once the domain is running.
Fixes: 74d2e11ccf ("mm: Scrub pages in alloc_heap_pages() if needed")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 83a784a15b
master date: 2026-02-05 08:53:07 +0100
Future changes will care about the state of the PGC_need_scrub flag even
when pages have the PGC_allocated set, and hence it's no longer possible to
alias both values. Also introduce PGC_need_scrub to the set of preserved
flags, so it's not dropped by assign_pages().
No functional change intended, albeit the page counter on x86 looses a bit.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: cbb484d008
master date: 2026-02-05 08:53:07 +0100
Don't know how I managed to overlook the freeing side when adding the case
to alloc_pdev().
Fixes: cd2b9f0b19 ("PCI: handle PCI->PCIe bridges as well in alloc_pdev()")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 74f984159f
master date: 2026-02-02 09:06:42 +0100
See the extensive code comment. This isn't really nice, but unless I'm
overlooking something there doesn't look to be a way to have the linker
strip individual symbols while doing its work.
Fixes: bf6501a62e ("x86-64: EFI boot code")
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
master commit: 45bb278934
master date: 2026-02-02 09:03:05 +0100
As amd_init_de_cfg() states, it's only safe for there to be one location
writing to DE_CFG. This happens to be a latent bug rather than a real one
because Fam12h CPUs aren't SMT-capable. Nevertheless, group it together with
the other DE_CFG modifications.
This removes a printk() which is not noteworthy, and skips the adjustment
entirely under virt, where the attempted write wouldn't have stuck anyway.
Fixes: d0c75dc4c0 ("x86/amd: Fix race editing DE_CFG")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: f49bbd301b
master date: 2026-01-27 13:59:12 +0000
It's not clear why only x86 had $(build_id_linker) applied to all three
linking passes. Not doing so will alter symbol offsets between the 2nd
and 3rd passes for, potentially, all of the symbols at higher addresses
(intermediate alignment padding may mask this effect, though, so it will
look as if problems appeared randomly).
Fixes: a353cab905 ("build_id: Provide ld-embedded build-ids")
Reported-by: Mykola Kvach <xakep.amatop@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Mykola Kvach <xakep.amatop@gmail.com> # arm
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com> # riscv
Tested-by: Jason Andryuk <jason.andryuk@amd.com> # arm64
Acked-by: Michal Orzel <michal.orzel@amd.com>
[jb: backport limited to Arm]
master commit: f0abe60de1
master date: 2026-01-27 10:26:36 +0100
Gcc's "threading" of conditionals can lead to undue warnings, as reported
in e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519 (no matter
that the overall situation is different there). While my gcc15 complains
("buf[2] may be used uninitialized in this function") about only two of
the three instances (not about the one in type_read()), adjust all three
to be on the safe side.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
master commit: 7db4509d80
master date: 2026-01-26 10:34:14 +0100
It's not clear why the enumerator was omitted, as these clearly shouldn't
take the "default" path (issuing a warning). Handle them the same as
legacy and PCIe->PCI bridges.
Fixes: e7e08d86ad ("IOMMU/PCI: consolidate pdev_type() and cache its result for a given device")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
master commit: cd2b9f0b19
master date: 2026-01-22 09:13:14 +0100
"cpuid=no-rdrand" cannot actually be used to suppress the respective
boot warning on certain AMD hardware. That's because cleared_caps[] are
only applied after the ->c_init() hooks ran, i.e. cpu_has() still
returns true in init_amd().
Fixes: 93401e28a8 ("x86: clear RDRAND CPUID bit on AMD family 15h/16h")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: f09f2e28a9
master date: 2026-01-22 09:10:10 +0100
Callers may pass in TSC values from before the local TSC stamp was last
updated (this would in particular be the case when the TSC was latched, a
time rendezvous occurs, and the latched value is used only afterwards).
scale_delta(), otoh, deals with unsigned values, and hence would treat
negative incoming deltas as huge positive values, yielding entirely bogus
return values.
Fixes: 88e64cb785 ("x86/HVM: use fixed TSC value when saving or restoring domain")
Reported-by: Антон Марков <akmarkov45@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 7b3e1b4e84
master date: 2026-01-20 09:03:17 +0100
XENMEM_claim_pages can be issued on a domain in the later stages of
domain_kill(). In that case, the claimed memory is leaked, as there's no way
to subsequently release the claim.
Claims are intended for use during domain construction; to reserve sufficient
RAM to construct the domain fully. There's no legitimate reason to be calling
it on a dying domain.
Fixes: 65c9792df6 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 2379ca04fe
master date: 2025-12-17 17:35:24 +0000
The previous logic attempted to skip an IBPB in the case of vCPU returning to
a CPU on which it was the previous vCPU to run. While safe for Xen's
isolation between vCPUs, this prevents the guest kernel correctly isolation
between tasks. Consider:
1) vCPU runs on CPU A, running task 1.
2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB.
3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB.
4) vCPU moves back to CPU A. Xen skips IBPB again.
Now, task 2 is running on CPU A with task 1's training still in the BTB.
Do the flush unconditionally when switching to a vCPU different than the
idle one. Note there's no need to explicitly gate the IBPB to next domain
!= idle, as the context where the IBPB is issued is subject to that
condition already unless the pCPU is going offline, at which point we don't
really care to issue an extra IBPB.
Also add a comment with the reasoning why the IBPB needs to be in
context_switch() rather than __context_switch().
This is XSA-479 / CVE-2026-23553.
Fixes: a2ed643ed7 ("x86/ctxt: Issue a speculation barrier between vcpu contexts")
Reported-by: David Kaplan <david.kaplan@amd.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 7beadd6119
master date: 2026-01-27 13:55:27 +0100
Jan Beulich
Andrew Cooper
Roger Pau Monné
Ross Lagerwall
Stewart Hildebrand
Teddy Astie
Juergen Gross
Edwin Török
Marek Marczykowski-Górecki
Anthony PERARD
Bertrand Marquis