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
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)
The Atom block used to fall through into the Phi block to get to it's
return false, and this was accidentally dropped with the Phi removal.
Fixes: 85191cf321 ("x86: drop Xeon Phi support")
Signed-off-by: Kevin Lampis <kevin.lampis@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: a2a34d7664
master date: 2026-01-12 13:07:36 +0100
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
The coloring allocator ignores claims; reject the usage of the hypercall if
LLC coloring is enabled. Note that the usage of alloc_color_heap_page() is
selected at boot time, and it's a system wide decision. Once enabled all
domains will use alloc_color_heap_page() for allocations, which ignores any
outstanding claims.
The hypercall can be enabled if/when LLC coloring is adjusted to support
claims.
Fixes: 95debe51a9 ("xen: add cache coloring allocator for domains")
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: b068cafc73
master date: 2026-01-07 15:54:33 +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
This is a partial backport of commit 63ebd0e964 ("releases: use newer
compression methods for tarballs"), but keeping gz as the only compression
method.
In addition to efficiency, this causes the tarball to use root/root ownership,
rather than leak whomever produced the tarball.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
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
Roger Pau Monné