The boot services FreePages() needs passing the size. Since we allocated
one more byte to put a trailing nul there, we also need to bump the size
passed there. Make a small helper function to centralize this.
Note that there's no permanent memory leak because of the oversight: The
allocation is done using EfiLoaderData, and all memory of that type is
later reclaimed anyway.
Fixes: df75f77092 ("EFI: avoid OOB config file reads")
Reported-by: Bernhard Kaindl <bernhard.kaindl@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Bernhard Kaindl <bernhard.kaindl@citrix.com>
Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>
master commit: 4ff927133e
master date: 2026-05-06 15:11:11 +0200
What c4f427ec87 ("xen: Swap order of actions in the FREE*() macros") did
should have been done right away when XVFREE() was introduced.
Fixes: 9102fcd957 ("mm: introduce xvmalloc() et al and use for grant table allocations")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 96ffccef5a
master date: 2026-05-06 15:11:11 +0200
Under SVM, there are two copies of guest CR2. One is v->arch.hvm.guest_cr[2]
and one is in the VMCB.
Xen doesn't intercept CR2 accesses, so this mostly goes unnoticed; hardware
loads and saves the guest CR2 in the VMCB across VMRUN/VMExit.
For HAP guests (where #PF is not intercepted, and therefore we don't typically
inject #PF either), this causes the guest CR2 value to be lost on migrate. As
migration is cooperative and not done from the #PF handler, this also goes
unnoticed by guests.
It also means that an emulated MOV-from-CR2 reads a stale value.
Reported-by: Stefano Stabellini <sstabellini@kernel.org>
Fixes: d1bd157fbc ("Big merge the HVM full-virtualisation abstractions.")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 3e6bca616b
master date: 2026-05-05 11:45:00 +0100
Gitlab CI reported a crash on boot on Alder Lake hardware. The bug is years
old, making it an incredibly rare occurance:
(XEN) *** DOUBLE FAULT ***
(XEN) ----[ Xen-4.22-unstable x86_64 debug=y ubsan=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82d04077bbc4>] arch/x86/setup.c#reinit_bsp_stack+0xfa/0x160
(XEN) RFLAGS: 0000000000010202 CONTEXT: hypervisor
(XEN) rax: 0000000000000007 rbx: ffff83049a4b0000 rcx: 00000000000006a2
(XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000
(XEN) rbp: ffff83049a4b7f00 rsp: ffff83049a4b7ef8 r8: ffff830497e47000
(XEN) r9: 00000000ffffffff r10: 00000000900c2121 r11: 000000009a392956
(XEN) r12: ffff830497e47000 r13: ffff830497e49f40 r14: 0000000000000000
(XEN) r15: ffff82d0407dad10 cr0: 0000000080050033 cr4: 0000000000f526e0
(XEN) cr3: 0000000043c16000 cr2: fffffffffffffffc
(XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008
(XEN) Xen code around <ffff82d04077bbc4> (arch/x86/setup.c#reinit_bsp_stack+0xfa/0x160):
(XEN) 00 b9 a2 06 00 00 0f 30 <80> 3d 71 26 f1 ff 00 74 3e 48 8d 93 f8 5f 00 00
(XEN) Valid stack range: ffff83049a4b6000-ffff83049a4b8000, sp=ffff83049a4b7ef8, tss.rsp0=ffff83049a4b7fb0
(XEN) No stack overflow detected. Skipping stack trace.
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) DOUBLE FAULT -- system shutdown
(XEN) ****************************************
This is on the instruction boundary after enabling CET (writing MSR_S_CET) and
prior to establishing SSP. Despite identifying this as a critical window
where any fault was deadly (the CPU tries to push a shadow stack frame at 0,
hence the CR2 value wrapping around to the top of the address space), I
clearly forgot that this meant interrupts too, which are enabled.
Disable interrupts during the critical period.
Fixes: b60ab42db2 ("x86/shstk: Activate Supervisor Shadow Stacks")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Teddy Astie <teddy.astie@vates.tech>
master commit: acfd2631b9
master date: 2026-05-05 11:45:00 +0100
The admin can control the upper bound wanted not only via command line
option, but also via XEN_SYSCTL_pm_op_set_max_cstate. While decisions how
to set up the system are okay this way as long as we deem the command line
option a strict upper bound, what to do during S3 resume should not be
based on that potentially varying value. Decisions there need to use
solely the strict upper bound we may have enforced ourselves (or which was
forced onto us via command line option).
Rather than altering pit_broadcast_is_available(), drop the function
altogether. It's pretty odd for acpi/cpu_idle.c to call into time.c, just
for that to call into acpi/cpu_idle.c again.
Fixes: 8d24303023 ("x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 93acfeb78b
master date: 2026-05-05 08:27:29 +0200
If a domain tries to map status frames in parallel to switching grant
table version from 2 to 1, the mapping operation may put in place P2M
entries referencing MFNs which gnttab_unpopulate_status_frames() is in the
process of freeing.
Ideally we would refcount pages when entered into P2M tables, but that's a
significant change. Extend the grant-table-locked region instead in
xenmem_add_to_physmap_one() (being the sole caller of gnttab_map_frame()),
such that a race with gnttab_unpopulate_status_frames() is no longer
possible.
This is XSA-486 / CVE-2026-23558.
Fixes: 5ce8fafa94 ("Dynamic grant-table sizing")
Fixes: a98dc13703 ("Introduce a grant_entry_v2 structure")
Reported-by: Rafal Wojtczuk <rafal.wojtczuk@7bulls.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
(cherry picked from commit 02708d3b51)
conn_delete_all_transactions() should be callable in any context,
resetting ALL transaction related data.
This includes number of active transactions and the transaction
pointer in struct connection.
So reset conn->trans to NULL in conn_delete_all_transactions() and
do the cleanup for each transaction in destroy_transaction().
This avoids triggering the assert() in conn_delete_all_transactions()
in case e.g. ignore_connection() was called while an operation inside
a transaction was performed, or XS_RESET_WATCHES was called in a
transaction.
This is XSA-484 / CVE-2026-23557.
Reported-by: Andrii Sultanov <andriy.sultanov@vates.tech>
Fixes: 1f9d04fb02 ("xenstored: allow guest to shutdown all its watches/transactions")
Signed-off-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit e88031d1fe)
The quota object contains both limits and the current node usage counts.
When a domain is torn down, the node data itself is cleaned up but the node
usage counts are not. A later domain reusing the same domid can create fewer
nodes before being deemed to be over quota.
Reset the count when the node permissions are cleaned up.
This is XSA-483 / CVE-2026-23556.
Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit af9e77f5ff)
The encoded MUL is 64 bits, so writes %rdx too. At a minimum, this needs
expressing as a clobber.
Also fix a logical disconnect between 'overflow' being the carry flag not the
overflow flag. CF and OF are always the same for MUL instructions, but update
the variable name to match the flag being checked.
Fixes: d5c70a51bf ("x86/APIC: handle overflow in TMICT calculation")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Fix the code which tries to pad the load segment to 2 MiB but only pads
it to a 1 MiB boundary.
This manifests as a page fault while scrubbing RAM during boot on certain
systems.
Xen fails to mark itself as reserved in the E820 (due to spanning multiple
regions), but does restrict the permissions in the directmap. The region of
RAM containing Xen is handed to physical memory manager as available for use,
and scrubbing hit the directmap protections.
Fixes: 4fb075201f ("x86/mkelf32: pad load segment to 2Mb boundary")
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 5416c455f6
master date: 2026-04-17 18:15:54 +0100
All arches truncate the cpu_khz without taking into account the less
significant digits. Instead use DIV_ROUND() when scaling from Hz to kHz
to get as more accurate kHz value.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 986707b461
master date: 2026-04-16 15:28:32 +0200
When running HVM guest in native TSC mode avoid using the recalculated vTSC
scaling factors based on the cpu_khz value. Using the kHz based frequency
leads to the TSC scaling values possibly not being the same as the ones
used by the per CPU cpu_time->tsc_scale field, which introduces skew
between the guest and Xen's calculations of the system time.
On a 2gHz system, where the frequency is possibly detected as 1999999999Hz
(note this is a worse-case scenario), the cpu_khz variable will be set to
1999999kHz, and hence 999Hz cycles will be not accounted for per second.
Over a second (the time synchronization period), this leads to a skew of:
cycles * 1 / (Hz freq) = 999 / 1999999999 = 499,5ns
So far this has gone unnoticed because the time synchronization rendezvous
forces the update of the tsc_timestamp and system_time fields in the vCPU
time info area, and hence the skew only accumulates up to the rendezvous
period. Attempting to remove the rendezvous causes the skew to grow
unbounded.
Fix by using the native TSC scaling values (as used by Xen) when the guest
TSC is not scaled.
Fixes: eab8a90be7 ("x86/time: scale host TSC in pvclock properly")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 305c6b901a
master date: 2026-04-16 15:28:32 +0200
The per-channel ENABLE bit is to solely be driven by hpet_enable_channel()
and hpet_msi_{,un}mask(). It doesn't need setting immediately. Except for
the (possible) channel put in legacy mode we don't do so during boot
either.
Instead reset ->arch.cpu_mask, to avoid msi_compose_msg() yielding an
all-zero message (when the passed in CPU mask has no online CPUs). Nothing
would later call msi_compose_msg() / hpet_msi_write(), and hence nothing
would later produce a well-formed message template in
hpet_events[].msi.msg.
Fixes: 15aa6c6748 ("amd iommu: use base platform MSI implementation")
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: c4d5119195
master date: 2026-04-16 10:44:16 +0200
With an expiry value on the order of 10 hours, and with a bus scale value
of 256k (as supplied by qemu), the (signed) multiplication will be UB. As
we've checked that the value is positive, we mean unsigned multiplication
anyway. Yet let's play safe against even larger expiry and bus scale
values, leveraging the compiler builtin that there is for this purpose.
While there also drop the stray cast from the actual TMICT write.
Fixes: 9062553a0d ("added time and accurate timer support")
Fixes: b95beb1858 ("x86: Clean up APIC local timer handling")
Reported-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Stewart Hildebrand <stewart.hildebrand@amd.com>
master commit: 4f14d97a62
master date: 2026-04-16 10:29:54 +0200
A killed timer will ignore further set_timer() calls, and hence won't be
re-armed unless it's initialized again. Use stop_timer() instead of
kill_timer() in time_suspend(), so that the set_timer() call in
time_resume() successfully re-arms the timer. Otherwise time calibration
is no longer scheduled (and executed) after resuming from S3 suspend.
Fixes: 6d90db1a2c ("x86: rendezvous-based local time calibration")
Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
master commit: 2d670d258b
master date: 2026-04-10 14:31:10 +0200
If the user has set baudrate as "auto" (use whatever was configured) but
Xen cannot find any set baudrate use a default fallback baudrate of
115200.
Otherwise the console will very likely end up being non-functional, as
further values are derived from the baudrate (like the transmit timeout),
and using -1 will result in screwed parameters being derived from the
baudrate.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>
master commit: 12e50da43d
master date: 2026-04-10 14:30:50 +0200
The supported features ELF notes was tested only if the dom0 was
PV. Factor out a function to check ELF notes and reuse it even
for PVH.
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 44429b6931
master date: 2026-04-09 21:04:58 +0100
We should not prematurely increment the pointer, to avoid inadvertently
skipping a NUL terminator.
Fixes: 6d9199bd0f ("x86-64: enable hypervisor output on VESA frame buffer")
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 3bcce461a3
master date: 2026-04-07 13:54:37 +0200
Advancing past a character without knowing whether that's the NUL char is
at risk of reading beyond the buffer.
Fixes: 25de1f6920 ("Allow arch-specific defaults to be specified for ns16550")
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 2c43b5611f
master date: 2026-04-07 13:54:19 +0200
strsep(), unless passed a 1st argument which itself points at a NULL
pointer, won't return NULL. Instead if the separator(s) looked for isn't
found, that pointed-to field would be updated to hold NULL. Hence the
important check in get_token() is for token to be non-NULL after the call
(which get_token()'s callers rely upon), while the checking of param_name
is left there just in case.
Fixes: 97fd49a7e0 ("ns16550: add support for UART parameters to be specifed with name-value pairs")
Reported-by: Kamil Frankowicz <kamil.frankowicz@cert.pl>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: b27d3b45c7
master date: 2026-04-07 13:53:49 +0200
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)
Jan Beulich