Rebase edera/4.22 onto staging-4.22 @ 61f8537254bd

[edera-rebase-app]

Nightly rebase of edera/4.22 (453724057660) onto staging-4.22 (61f8537254bd), driven by Claude. Not pushed automatically because the checker found no result (it did not run). Run log.

Important

Do not use the merge button: this branch replaces edera/4.22 rather than merging into it. Approve the pull request to land it; the land workflow force-pushes edera/4.22 to this exact head, pinned to 453724057660, and keeps a backup.

Independent checks

Builds: success (x86, arm64, arm64 + PCI_PASSTHROUGH; per-build results in the run).

The checker did not run.

Claude's report

Summary

I rebased edera/4.22 (453724057660) from 1a36aac500bb onto upstream staging-4.22 61f8537254bd. The upstream range has 22 commits, 0822a2e890..61f8537254. All 221 downstream commits replayed with no textual conflicts and none were dropped. On the clean replay the checker passed fully (same patch-ids, zero drift). It will now fail on purpose: one downstream commit, [FUTURE] xen/arm: enable vPCI for dom0 (now d9698ed9f9), was amended. Upstream 0822a2e890 loosens a vPCI check, and without the amendment the hardware domain on Arm could fault the hypervisor through the downstream-only Arm dom0 vPCI path. The checker should report that one changed commit and 14 added lines of drift in xen/arch/arm/vpci.c, and nothing else. All three builds pass.

Needs a decision

• UNSURE: Arm hardware-domain unaligned vPCI accesses after upstream 0822a2e890 ("xen/vpci: allow unaligned accesses by the hardware domain").
  • What upstream changed. The commit relaxes vpci_access_allowed() so the hardware domain may make unaligned config-space accesses. It makes them safe on x86 only, by fixing pci_conf_{read,write}{16,32}() in xen/arch/x86/x86_64/pci.c. In upstream 4.22, the Arm hardware domain never gets vPCI, so Arm does not need the fix there.
  • Why it matters downstream. Downstream [FUTURE] xen/arm: enable vPCI for dom0 sets XEN_DOMCTL_CDF_vpci for Arm dom0. On Arm, the only alignment check on the trap path (vpci_mmio_{read,write} → vpci_ecam_{read,write}) was vpci_access_allowed().
  • What could go wrong. After a clean replay, an unaligned 2- or 4-byte dom0 access to a register vPCI does not handle would reach vpci_read_hw()/vpci_write_hw(). From there it goes through pci_conf_*16/32 and pci_generic_config_{read,write}() to readw/readl/writew/writel on an unaligned ECAM (Device memory) address, at EL2. That is an alignment fault in Xen.
  • Caveat. I could not determine whether real dom0 kernels on Arm can produce a trapped unaligned access with a valid ISS. Stage-1 Device mappings would fault inside the guest first. Treat this as a plausible crash, not a demonstrated one.
  • Reading A (what I committed, the conservative option). Keep Arm's pre-rebase behaviour exactly. I added an IS_ALIGNED(info->gpa, access size) check at the top of vpci_mmio_read()/vpci_mmio_write() in xen/arch/arm/vpci.c. On failure it returns 0, which is exactly what dom0 got before this rebase when vpci_access_allowed() refused the access. x86 keeps the new upstream behaviour.
  • Reading B. Arm should follow upstream's intent: the ACPI-originated unaligned accesses that motivated the change could also come from the downstream Arm ACPI hardware domain. That needs Arm's config accessors to split unaligned accesses the way the x86 MMCFG fix does, which is a real design change I would not make unattended. If you prefer B, drop my hunk and implement the split in xen/arch/arm/pci/pci-access.c.
  • Where the change lives. I put it in the commit that exposes the path, not in a rebase: fix-up. If you prefer the clean replay, git rebase that commit back to its original content; the checker then passes with zero drift.

Conflicts resolved

None. Every commit applied cleanly. The one deliberate change is described under "Needs a decision" and was not a conflict.

Dropped downstream commits

None.

Build fixes

None needed. All builds passed on the clean replay. The only amendment is the semantic one above, made in [FUTURE] xen/arm: enable vPCI for dom0 (d9698ed9f9, was ce82c3584e before this rebase).

New upstream commits

• 61f8537254 x86/mkelf32: correct VA/PA of PT_NOTE / .note
• a067d640ab x86emul: Fix AAM emulation AH output
• 3703b32f36 x86/boot: Force error checking for reserve_e820_ram()
• 52d71fc560 vmx: Handle TDX instruction exit reasons
• 85f95eed7b x86/viridian: Workaround Hyper-V GP fault writing to MSR
• 2a797c6d6e xen/sched: core: skip missing vcpu slots in sched_move_domain()
• 13bd631cef x86/pci: prevent cross-device accesses in pci_mmcfg_{read,write}()
• 3ffc21956e xen/arm: report proper GIC version via XEN_DOMCTL_getdomaininfo
• 781b60f951 xen/arm: Fix evaluation of parameters for SMCCC calls
• 3375d22835 xen/arm: traps: report level 0 faults in panic_PAR()
• 84cc114ffd xen/arm: Hide PMU registers from the guest, when the vPMU feature is disabled
• 6a3824e4d6 xen/arm: drop incorrect EL0 accessibility comments for PMINTEN{SET,CLR}
• 39b09ab61f xen/arm: propagate secondary GIC initialization failures
• a6382ae784 xen/dt: reject "xen,static-mem" when CONFIG_STATIC_MEMORY is disabled
• 5c84622f4f xen/arm: mask debug exceptions in initial AArch64 guest state
• b8fe9e3374 x86/ucode: Work around Granite Rapids erraturm GNR98
• cc07f4b058 EFI: don't use alias attribute for compat hypercall stubs
• 2896911c95 build: also exclude .data.rel.ro in $(cmd_obj_init_o)
• a9df8eb103 libacpi: drop mk_dsdt's -d / --debug option
• 2bd89c0ef3 x86/pci: Perform XSM checks on the correct device in pci_conf_write_intercept()
• f692b1badf xen/sched: core: kill unarmed timers on sched_init_vcpu() failure
• 0822a2e890 xen/vpci: allow unaligned accesses by the hardware domain

XSA audit

No XSAs in this range. git log --grep='XSA' over MB..UPSTREAM returns nothing.

I also checked every upstream commit that touches a file downstream modifies, reading the final tree:

• 0822a2e890 (xen/drivers/vpci/vpci.c): the new vpci_access_allowed() is intact in the final tree, and the downstream vPCI commits do not change it. The Arm consequence is covered under "Needs a decision".
• 39b09ab61f (gic.c, gic.h, smpboot.c): the only secondary_init implementations are gicv2_secondary_cpu_init and gicv3_secondary_cpu_init. The single caller, smpboot.c, checks the new int return. Downstream's gic.c changes (MADT GIC version discovery, longer GICC subtables) don't touch this path.
• a9df8eb103 (tools/libacpi/mk_dsdt.c): downstream libacpi: describe guest CPUs with Device() on Arm never uses the removed debug variable. A tree-wide grep of tools/libacpi finds no debug at all, which matters because the CI builds don't compile tools.
• 5c84622f4f, 3ffc21956e, 84cc114ffd (arch-arm.h, domain.c, cpufeature.h): the hunks merged next to downstream edits (MAX_VIRT_CPUS, the second redistributor region, the vGIC late_init, the Spectre-BHB fields) without interacting with them.
• 3703b32f36 (x86/setup.c): the new panics on reserve_e820_ram() failure are intact. Downstream setup.c changes (PVH upgrade, vNUMA, vPCI flag) are elsewhere in the file.
• 13bd631cef, 2bd89c0ef3 (security-relevant x86 PCI fixes): no downstream commit touches x86/pci.c, x86_64/pci.c or mmconfig_64.c.

Builds

• x86 defconfig: pass
• arm64 defconfig: pass
• arm64 + EXPERT + PCI_PASSTHROUGH (compiles arch/arm/vpci.o): pass

[github-actions]

PR Review

Reviewed at e15ec4c.

This check did not finish, so it has nothing to say about the diff. The run log has the reason.

Test Coverage

Reviewed at e15ec4c.

This check did not finish, so it has nothing to say about the diff. The run log has the reason.

[github-actions]

Merged into the review above.

[github-actions]

Landed by @kaniini's approval: edera/4.22 is now e15ec4c9bdc2 (was 453724057660, kept as backup/edera-4.22-pre-rebase-20261008-453724057660).