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
Guests can do wider-than-PTE-size writes on page tables. The tracing
helper variable, however, only offers space for a single PTE (and it is
being switched to the more correct type right here). Therefore bound
incoming write sizes to the amount of space available.
To not leave dead code (which is a Misra concern), drop the now unused
guest_pa_t as well.
Also move and adjust GUEST_PTE_SIZE: Derive it rather than using hard-
coded numbers, and put it in the sole source file where it's actually
needed. This then also addresses a Misra rule 20.9 ("All identifiers
used in the controlling expression of #if or #elif preprocessing
directives shall be #define'd before evaluation") violation:
GUEST_PAGING_LEVELS is #define'd only in multi.c.
This is XSA-477 / CVE-2025-58150.
Fixes: 9a86ac1aa3 ("xentrace 5/7: Additional tracing for the shadow code")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: a6626b613a
master date: 2026-01-27 13:55:01 +0100
Update to latest 14.3.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
(cherry picked from commit 331f94d0bb)
cirrus-ci: introduce FreeBSD 15.0-RELEASE as "current" version
Switch the current version to 15.0-RELEASE. Sadly the 16 snapshot images
are not working, hence use the FREEBSD_CURRENT variable as a placeholder
for 15.0 until the issues with FreeBSD 16.0 snapshot images is solved.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit cfb767759b)
Its sole caller is, and the wrong annotation would cause a build failure
(non-empty .text) if the compiler chose to not inline the function when at
the same time LATE_HWDOM=y.
Fixes: be52cb139f ("x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: bdd5f35cf2
master date: 2026-01-08 11:05:30 +0100
The current logic splits the update of the amount of available memory in
the system (total_avail_pages) and pending claims into two separately
locked regions. This leads to a window between counters adjustments where
the result of total_avail_pages - outstanding_claims doesn't reflect the
real amount of free memory available, and can return a negative value due
to total_avail_pages having been updated ahead of outstanding_claims.
Fix by adjusting outstanding_claims and d->outstanding_pages in the same
place where total_avail_pages is updated. Note that accesses to
d->outstanding_pages is protected by the global heap_lock, just like
total_avail_pages or outstanding_claims. Add a comment to the field
declaration, and also adjust the comment at the top of
domain_set_outstanding_pages() to be clearer in that regard.
Note that failures in assign_pages() causes the claimed amount that has
been allocated to be lost, as the amount is not added back to the domain
quota once pages are freed. Given the intended usage of claims is limited
to initial physmap populate, and the current failure paths in
assign_pages() would lead to the domain being destroyed anyway, don't
add extra logic to recover the claimed amount on failure - it's just adding
complexity for no real benefit.
Fixes: 65c9792df6 ("mmu: Introduce XENMEM_claim_pages (subop of memory ops)")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 75d29d9b5e
master date: 2026-01-08 11:05:30 +0100
XENMAPSPACE_gmfn{_range} allows moving gfn around the guest p2m: the mfn
behind the source gfn is zapped from the origin and mapped at the
requested destination gfn. The destination p2m entries are always created
with type p2m_ram_rw.
With the current checking done in xenmem_add_to_physmap_one() it's possible
to use XENMAPSPACE_gmfn{_range} to change the type of a p2m entry. The
source gfn is only checked to be not shared, and that the underlying page
is owned by the domain.
Make the source checks more strict, by checking that the source gfn is of
type read/write RAM or logdirty. That prevents the operation from
inadvertently changing the type as part of the move.
Fixes: 3e50af3d87 ("New XENMAPSPACE_gmfn parameter for XENMEM_add_to_physmap.")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: c9491ea21a
master date: 2026-01-08 11:05:30 +0100
Pass the TPM2 ACPI table so that the device can be found by a PVH dom0.
Otherwise dom0 shows:
tpm_tis MSFT0101:00: [Firmware Bug]: failed to get TPM2 ACPI table
tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -22
TCPA is "Trusted Computing Platform Alliance table", but it is really
the table for a TPM 1.2. Pass that as well.
While doing this, move ACPI_SIG_WPBT to alpabetize the entries.
This exposes TPM event log tables on PVH dom0, bring it in line with a
PV dom0.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 46f3ed0d53
master date: 2025-12-16 09:40:18 +0100
Just like for PV guests MMU_MACHPHYS_UPDATE implies marking of the
respective page as dirty, additions to a HVM guest's P2M should do so.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
[jb: backport limited to the new paging_mark_pfn_dirty() use]
master commit: 98fccdf0ac
master date: 2025-12-11 09:50:30 +0100
Add the missing index increase in the M2P clearing loop, otherwise the loop
keeps pointlessly setting the same MFN entry repeatedly. This seems to be
an oversight from the change that introduced support to process high order
pages in one go.
Fixes: 3c352011c0 ("x86/PoD: shorten certain operations on higher order ranges")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: 8e4d495cb8
master date: 2025-12-11 09:50:10 +0100
We have two different functions explaining that DE_CFG is Core-scoped and that
writes are racy but happen to be safe. This is only true when there's one of
them.
Introduce amd_init_de_cfg() to be the singular function which writes to
DE_CFG, modelled after the logic we already have for BP_CFG.
While reworking amd_check_zenbleed() into a simple predicate used by
amd_init_de_cfg(), fix the microcode table. The 'good_rev' was specific to an
individual stepping and not valid to be matched by model, let alone a range.
The only CPUs incorrectly matched that I can locate appear to be
pre-production, and probably didn't get Zenbleed microcode.
Rework amd_init_lfence() to be amd_init_lfence_dispatch() with only the
purpose of configuring X86_FEATURE_LFENCE_DISPATCH in the case that it needs
synthesising. Run it on the BSP only and use setup_force_cpu_cap() to prevent
the bit disappearing on a subseuqent CPUID rescan.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: d0c75dc4c0
master date: 2025-12-01 16:20:41 +0000
This was potentially helpful when the chickenbit was the only mitigation and
microcode had not been released, but that was two years ago.
Zenbleed microcode has been avaialble since December 2023, and the subsequent
Entrysign signature vulnerability means that firmware updates block OS-loading
and more OS-loadable microcode will be produced for Zen2.
i.e. the Zenbleed fix is not going to appear at runtime these days.
No practical change.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: 5cd1ac1575
master date: 2025-11-27 18:22:20 +0000
When setting a timer's config register, timer_sanitize_int_route will
always reset the IRQ route value to what's valid corresponding to the
!HPET_CFG_LEGACY case. This is applied even if the HPET is set to
HPET_CFG_LEGACY.
When some operating systems (e.g. Windows) try to write to a timer
config, they will verify and rewrite the register if the values don't
match what they expect. This causes an unnecessary write to HPET_Tn_CFG.
Note, the HPET specification states that for the Tn_INT_ROUTE_CNF field:
"If the value is not supported by this prarticular timer, then the value
read back will not match what is written. [...] If the LegacyReplacement
Route bit is set, then Timers 0 and 1 will have a different routing, and
this bit field has no effect for those two timers."
Therefore, Xen should not reset timer_int_route if legacy mode is
enabled, regardless of what's in there.
Fixes: ec40d3fe21 ("x86/vhpet: check that the set interrupt route is valid")
Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: fb0e37df71
master date: 2025-11-26 12:10:21 +0100
The usage of atomic_dec_and_test() in msixtbl_pt_unregister() is inverted:
the function will return true when the refcount reaches 0. The current
code does the opposite and calls del_msixtbl_entry() when there are still
refcounts held on the object.
However all callers of msixtbl_pt_unregister() are serialized on the domctl
lock, and hence there cannot be parallel calls to msixtbl_pt_unregister()
that could lead to double freeing of the same object.
The incorrect freeing with active msixtlb entries will result in a possible
guest visible malfunction, but no internal Xen state corruption.
While entries are leaked once the last pIRQ is unbound, the same entry
would get re-used if the device has pIRQs bound again. The guest cannot
exploit this incorrect refcount check to leak arbitrary amounts of memory
by repeatedly enabling and disabling (binding and unbinding) MSI-X entries.
Fixes: 34097f0d30 ('hvm: passthrough MSI-X mask bit acceleration')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: ea87662c77
master date: 2025-11-26 09:46:17 +0100
The xen-ucode utility is sensitive to the overall error as -EEXIST is a
special case for success, but the real error can get clobbered with -EBUSY.
This can be demonstrated most easily by force loading an old microcode, which
should yield -EIO but yields -EBUSY:
# xen-ucode /lib/firmware/amd-ucode/microcode_amd_fam17h.bin --force
Failed to update microcode. (err: Device or resource busy)
(XEN) 256 cores are to update their microcode
(XEN) microcode: CPU0 update rev 0x830107d to 0x830107c failed, result 0x830107d
(XEN) Late loading aborted: CPU0 failed to update ucode: -5
wait_for_state() returns false on encountering LOADING_EXIT. Right now, this
is always transformed into -EBUSY and passed back to callers.
However, control_thread_fn() can move directly to this state in the case of an
early error; it is not an error condition for APs, but the latest write into
stopmachine_data.fn_result wins, causing the real error, -EIO, to get
clobbered with -EBUSY.
Drop all the -EBUSY's, and treat hitting LOADING_EXIT as a success case. This
causes only a single error to be returned through stop_machine_run(), and
preserves the -EIO
# xen-ucode /lib/firmware/amd-ucode/microcode_amd_fam17h.bin --force
Failed to update microcode. (err: Input/output error)
(XEN) 256 cores are to update their microcode
(XEN) microcode: CPU0 update rev 0x830107d to 0x830107c failed, result 0x830107d
(XEN) Late loading aborted: CPU0 failed to update ucode: -5
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: a405bf42ed
master date: 2025-11-24 15:17:39 +0000
The error messages that the compiler may emit can be confusing.
The check was also the wrong way round in case multiple make targets are
specified: We want to do the check whenever targets other than the running
and cleaning ones are specified.
Fixes: 05f4cc2192 ("x86emul: suppress default test harness build with incapable compiler")
Fixes: d5997399b7 ("x86emul: suppress "not built" warning for test harness'es run targets")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: c482d1f59f
master date: 2025-11-24 11:28:47 +0100
Many *.c files are symlinked while building, so along with generated *.h
files they ought to be removed. Conversely $(TARGET) doesn't need removing
twice.
Fixes: cb4fcf70b2 ("x86emul: parallelize SIMD test code building")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: 774c382b28
master date: 2025-11-13 09:08:27 +0100
These files 'docs/misc/kconfig{,-language}.txt' were deleted, but
references are still present in Xen. Remove them to clean-up.
Fixes: 044503f61c ("docs: Delete kconfig docs to fix licensing violation")
Fixes: f80fe2b34f ("xen: Update Kconfig to Linux v5.4")
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
master commit: c22b6dced0
master date: 2025-11-11 14:44:47 +0100
The stimer enlightment was removed from the defaults list in commit
e83077a3d1 ("libxl: don't enable synthetic timers by default") but the
corresponding docs change was not made. Removing from docs as enabling the
enlightenment will hang Windows 10 guests.
Fixes: e83077a3d1 ("libxl: don't enable synthetic timers by default")
Signed-off-by: James Dingwall <james@dingwall.me.uk>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: d510f9c143
master date: 2025-11-10 16:56:03 +0000
The default terminal settings in Linux will enable echo which interferes with
these tests. Set the value in the script to avoid failure caused by a settings
reset.
Signed-off-by: Victor Lira <victorm.lira@amd.com>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(cherry picked from commit 2f73ef4bd7)
Otherwise it's not possible for device models to map IRQs of devices on
segments different than 0. Keep the same function prototype and pass the
segment in the high 16bits of the bus parameter, like it's done for the
hypercall itself.
Amends: 7620c0cf9a ("PCI multi-seg: add new physdevop-s")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
master commit: b7838d12bd
master date: 2025-10-21 16:56:19 +0100
With large NR_CPUS on-stack cpumask_t variables are problematic. Now that
the IRQ handler can't be invoked in a nested manner anymore, we can
instead use a per-CPU variable. While we can't use scratch_cpumask in code
invoked from IRQ handlers, simply amend that one with a HPET-special form.
(Note that only one of the two IRQ handling functions can come into play
at any one time.)
Fixes: 996576b965 ("xen: allow up to 16383 cpus")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 80c7c67164
master date: 2025-10-29 09:02:53 +0100
If a SR-IOV card presents an I/O space inside a BAR the
code will continue to loop on the same card.
This is due to the missing increment of the cycle variable.
Fixes: a1a6d59862 ("pci: split code to size BARs from pci_add_device")
Signed-off-by: Frediano Ziglio <frediano.ziglio@cloud.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
master commit: f7091c0e1f
master date: 2025-10-27 15:52:20 +0100
Using dynamically allocated / maintained vectors has several downsides:
- possible nesting of IRQs due to the effects of IRQ migration,
- reduction of vectors available for devices,
- IRQs not moving as intended if there's shortage of vectors,
- higher runtime overhead.
As the vector also doesn't need to be of any priority (first and foremost
it really shouldn't be of higher or same priority as the timer IRQ, as
that raises TIMER_SOFTIRQ anyway), simply use the lowest one above the
legacy range. The vector needs reserving early, until it is known whether
it actually is used. If it isn't, it's made available for general use.
With a fixed vector, less updating is now necessary in
set_channel_irq_affinity(); in particular channels don't need transiently
masking anymore, as the necessary update is now atomic. To fully leverage
this, however, we want to stop using hpet_msi_set_affinity() there. With
the transient masking dropped, we're no longer at risk of missing events.
AMD interrupt remapping code so far didn't "return" a consistent MSI
address when translating an MSI message. Clear respective fields there, to
keep the related assertion in set_channel_irq_affinity() from triggering.
Fixes: 996576b965 ("xen: allow up to 16383 cpus")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 8ef32772b5
master date: 2025-10-27 15:51:42 +0100
Keeping channels enabled when they're unused is only causing problems:
Extra interrupts harm performance, and extra nested interrupts could even
have caused worse problems. However, on all Intel hardware I looked at
closely, a 0->1 transition of the enable bit causes an immediate IRQ.
Hence disabling channels isn't a good idea there. Set a "long" timeout
instead.
Along with that also "clear" the channel's "next event", for it to be
properly written by whatever the next user is going to want (possibly
avoiding too early an IRQ).
Further, along the same lines, don't enable channels early when starting
up an IRQ. This doesn't need to happen earlier than from
set_channel_irq_affinity() (once a channel goes into use the very first
time). This eliminates a single instance of
(XEN) [VT-D]INTR-REMAP: Request device [0000:00:1f.0] fault index 0
(XEN) [VT-D]INTR-REMAP: reason 25 - Blocked a compatibility format interrupt request
during boot. (Why exactly there's only one instance, when we use multiple
counters and hence multiple IRQs, I can't tell. My understanding would be
that this was due to __hpet_setup_msi_irq() being called only after
request_irq() [and hence the .startup handler], yet that should have
affected all channels.)
Fixes: 3ba523ff95 ("CPUIDLE: enable MSI capable HPET for timer broadcast")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 24f608dc90
master date: 2025-10-27 15:51:03 +0100
A .disable handler can't typically be re-used for .ack: The latter needs
to deal with IRQ migration, while the former shouldn't. Furthermore
invoking just irq_complete_move() isn't enough; one of
move_{native,masked}_irq() also needs invoking.
Fixes: 487a1cffd7 ("x86: Implement per-cpu vector for xen hypervisor")
Fixes: f821102450 ("x86: IRQ Migration logic enhancement")
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: aed6278b2a
master date: 2025-10-21 14:11:45 +0200
By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
when linking xen.efi. Due to the nature of file symbols in COFF symbol
tables (see the code comment) the symbols_offsets[] entries for such
symbols would cause assembler warnings regarding value truncation. Of
course the resulting entries would also be both meaningless and useless.
Add a heuristic to get rid of them, really taking effect only when
--all-symbols is specified (otherwise these symbols are discarded
anyway).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
master commit: 2f21ce1a6a
master date: 2025-10-21 14:10:46 +0200
When Entrysign has been mitigated in firwmare, it is believed to be safe to
rely on the CPU patchloader again. This avoids us needing to maintain the
digest table for all new microcode indefinitely.
Relax the digest check when firmware looks to be up to date, and leave behind
a clear message when not.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
This is best-effort only. If a malicious microcode has been loaded prior to
Xen running, then all bets are off.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit ff8228ab46)
After initial publication, the SB-7033 / CVE-2024-36347 bulletin was updated
to list Zen5 CPUs as vulnerable. Use Fam1ah as an upper bound, and adjust the
command line documentation.
When the Zen6 (also Fam1ah processors) model numbers are known, they'll want
excluding from the range.
Fixes: 630e8875ab ("x86/ucode: Perform extra SHA2 checks on AMD Fam17h/19h microcode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit c2529496d0)
For Zen3-5 microcode blobs signed with the updated signature scheme, the
checksum field has been reused to be a min_revision field, referring to the
microcode revision which fixed Entrysign (SB-7033, CVE-2024-36347).
Cross-check this when trying to load microcode, but allow --force to override
it. If the signature scheme is genuinely different, a #GP will occur.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit b3f015b8ba)
[Note: --force doesn't exist in this version of Xen]
EIO is not the only error that ucode_ops.apply_microcode() can produce.
EINVAL, EEXISTS and ENXIO can be generated too, each of which mean that Xen is
unhappy in some way with the proposed blob.
Some of these can be bypassed with --force, which will cause the parallel load
to be attempted.
Fixes: 5ed12565aa ("microcode: rendezvous CPUs in NMI handler and load ucode")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Release-Acked-By: Oleksii Kurochko <oleksii.kurochko@gmail.com>
(cherry picked from commit e0bb712a28)
[Note: --force doesn't exist in this version of Xen]
Currently, the URL where the ECLAIR MISRA C scan reports are saved
is hardcoded; making it configurable allows multiple runners and storage
servers to be used without resorting to publishing all artifacts
to the same report server.
Additionally, reports will be accessed publicly by using a proxy,
therefore the address that needs to be printed in GitLab analysis logs
is that of the public url, rather than the location where they are stored.
Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
[stefano: remove unneeded exports]
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
Reviewed-by: Anthony PERARD <anthony.perard@vates.tech>
(cherry picked from commit bea38de1bd)
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: 50b649c742 ("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
Jan Beulich