CHANGELOG.md | 2 + tools/flask/policy/modules/dom0.te | 1 - tools/include/xenguest.h | 1 - tools/libs/guest/xg_cpuid_x86.c | 14 --- xen/arch/x86/boot/head.S | 1 - xen/arch/x86/boot/trampoline.S | 29 +++--- xen/arch/x86/boot/wakeup.S | 27 +++--- xen/arch/x86/cpu/amd.c | 107 ++++++++++++++------ xen/arch/x86/cpu/common.c | 135 +++++++++++++------------- xen/arch/x86/cpu/cpu.h | 7 +- xen/arch/x86/cpu/hygon.c | 2 + xen/arch/x86/cpu/intel.c | 74 ++++---------- xen/arch/x86/domain.c | 10 +- xen/arch/x86/flushtlb.c | 19 ++-- xen/arch/x86/include/asm/cpuid.h | 17 ++-- xen/arch/x86/include/asm/hvm/hvm.h | 2 + xen/arch/x86/include/asm/hvm/vlapic.h | 2 + xen/arch/x86/include/asm/hvm/vpt.h | 2 + xen/arch/x86/include/asm/trampoline.h | 7 +- xen/arch/x86/sysctl.c | 6 -- xen/include/public/sysctl.h | 22 +---- xen/xsm/flask/hooks.c | 4 - xen/xsm/flask/policy/access_vectors | 2 - 23 files changed, 238 insertions(+), 255 deletions(-)
I was hoping this to be a patch or two, but it got out of hand... https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx The branch has one extra patch to fake up the firmware settings being set to Gitlab CI, not included in this series. Julien: This ought to suitable to rebase your cleanup on to. In the end, I did the AMD adjustment mostly because I needed it to test the correctness of the prior cleanup. The final 4 patches are tangential cleanup which I've kept out of the prior work in case we wish to backport it. Everything prior is relevant to untangling, and mostly for the benefit of the AMD side. The early patches are hopefully non-controvertial. Later patches are a little more RFC, and in need of further testing. Andrew Cooper (16): x86/cpu: Fix boot time cache flushing x86/cpu: Drop cpuid_level adjustment from generic_identify() x86/intel: Drop the paddr_bits workaround for P4 Nocona/Prescott CPUs x86/cpu: Fold generic_identify() into its single caller x86/cpu: Move per-CPU actions out of the vendor early_init() hook x86/cpu: Rework the vendor early_init() hooks to be __init x86/cpu: Call the vendor early_init() hook in early_cpu_init() xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps x86/intel: Always check MSR_MISC_ENABLE on all CPUs x86/amd: Always probe and configure the masking MSRs x86/amd: Fix re-activation of TopoExt on Fam15h CPUs x86/amd: Probe for NX support and re-activate if possible x86/cpu: Drop NOISY_CAPS x86/cpu: Drop default_init() and default_cpu x86/cpu: Clean up use of LCAP_* constants x86/cpuid: Drop the include of public/sysctl.h CHANGELOG.md | 2 + tools/flask/policy/modules/dom0.te | 1 - tools/include/xenguest.h | 1 - tools/libs/guest/xg_cpuid_x86.c | 14 --- xen/arch/x86/boot/head.S | 1 - xen/arch/x86/boot/trampoline.S | 29 +++--- xen/arch/x86/boot/wakeup.S | 27 +++--- xen/arch/x86/cpu/amd.c | 107 ++++++++++++++------ xen/arch/x86/cpu/common.c | 135 +++++++++++++------------- xen/arch/x86/cpu/cpu.h | 7 +- xen/arch/x86/cpu/hygon.c | 2 + xen/arch/x86/cpu/intel.c | 74 ++++---------- xen/arch/x86/domain.c | 10 +- xen/arch/x86/flushtlb.c | 19 ++-- xen/arch/x86/include/asm/cpuid.h | 17 ++-- xen/arch/x86/include/asm/hvm/hvm.h | 2 + xen/arch/x86/include/asm/hvm/vlapic.h | 2 + xen/arch/x86/include/asm/hvm/vpt.h | 2 + xen/arch/x86/include/asm/trampoline.h | 7 +- xen/arch/x86/sysctl.c | 6 -- xen/include/public/sysctl.h | 22 +---- xen/xsm/flask/hooks.c | 4 - xen/xsm/flask/policy/access_vectors | 2 - 23 files changed, 238 insertions(+), 255 deletions(-) -- 2.39.5
Le 26/01/2026 à 18:56, Andrew Cooper a écrit : > I was hoping this to be a patch or two, but it got out of hand... > > https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 > https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx > > The branch has one extra patch to fake up the firmware settings being set to > Gitlab CI, not included in this series. > > Julien: This ought to suitable to rebase your cleanup on to. In the end, I > did the AMD adjustment mostly because I needed it to test the correctness of > the prior cleanup. > > The final 4 patches are tangential cleanup which I've kept out of the prior > work in case we wish to backport it. Everything prior is relevant to > untangling, and mostly for the benefit of the AMD side. > > The early patches are hopefully non-controvertial. Later patches are a little > more RFC, and in need of further testing. > > Andrew Cooper (16): > x86/cpu: Fix boot time cache flushing > x86/cpu: Drop cpuid_level adjustment from generic_identify() > x86/intel: Drop the paddr_bits workaround for P4 Nocona/Prescott CPUs > x86/cpu: Fold generic_identify() into its single caller > x86/cpu: Move per-CPU actions out of the vendor early_init() hook > x86/cpu: Rework the vendor early_init() hooks to be __init > x86/cpu: Call the vendor early_init() hook in early_cpu_init() > xen/sysctl: Drop XEN_SYSCTL_get_cpu_levelling_caps > x86/intel: Always check MSR_MISC_ENABLE on all CPUs > x86/amd: Always probe and configure the masking MSRs > x86/amd: Fix re-activation of TopoExt on Fam15h CPUs > x86/amd: Probe for NX support and re-activate if possible > x86/cpu: Drop NOISY_CAPS > x86/cpu: Drop default_init() and default_cpu > x86/cpu: Clean up use of LCAP_* constants > x86/cpuid: Drop the include of public/sysctl.h > > CHANGELOG.md | 2 + > tools/flask/policy/modules/dom0.te | 1 - > tools/include/xenguest.h | 1 - > tools/libs/guest/xg_cpuid_x86.c | 14 --- > xen/arch/x86/boot/head.S | 1 - > xen/arch/x86/boot/trampoline.S | 29 +++--- > xen/arch/x86/boot/wakeup.S | 27 +++--- > xen/arch/x86/cpu/amd.c | 107 ++++++++++++++------ > xen/arch/x86/cpu/common.c | 135 +++++++++++++------------- > xen/arch/x86/cpu/cpu.h | 7 +- > xen/arch/x86/cpu/hygon.c | 2 + > xen/arch/x86/cpu/intel.c | 74 ++++---------- > xen/arch/x86/domain.c | 10 +- > xen/arch/x86/flushtlb.c | 19 ++-- > xen/arch/x86/include/asm/cpuid.h | 17 ++-- > xen/arch/x86/include/asm/hvm/hvm.h | 2 + > xen/arch/x86/include/asm/hvm/vlapic.h | 2 + > xen/arch/x86/include/asm/hvm/vpt.h | 2 + > xen/arch/x86/include/asm/trampoline.h | 7 +- > xen/arch/x86/sysctl.c | 6 -- > xen/include/public/sysctl.h | 22 +---- > xen/xsm/flask/hooks.c | 4 - > xen/xsm/flask/policy/access_vectors | 2 - > 23 files changed, 238 insertions(+), 255 deletions(-) > Tested on a Intel machine with "DEP" disabled, and "Require NX support" disabled, I get a pagefault in hpet code > (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 > (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd > (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac > (XEN) re-enabled NX (Execute Disable) protection > (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) > (XEN) BSP microcode revision: 0x0000001a > (XEN) microcode: Bad data in container > (XEN) Microcode: Parse error -22 > (XEN) Bootloader: EFI > (XEN) Command line: dom0_mem=2G iommu=verbose,debug console=com1 com1=115200,8n1 guest_loglvl=all loglvl=all > (XEN) Xen image load base address: 0xc3a00000 > (XEN) Video information: > (XEN) VGA is graphics mode 1920x1080, 32 bpp > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) Disc information: > (XEN) Found 0 MBR signatures > (XEN) Found 1 EDD information structures > (XEN) EFI RAM map: > (XEN) [0000000000000000, 000000000004efff] (usable) > (XEN) [000000000004f000, 000000000004ffff] (reserved) > (XEN) [0000000000050000, 000000000009dfff] (usable) > (XEN) [000000000009e000, 000000000009ffff] (reserved) > (XEN) [0000000000100000, 00000000c60c3fff] (usable) > (XEN) [00000000c60c4000, 00000000c60cafff] (ACPI NVS) > (XEN) [00000000c60cb000, 00000000c650ffff] (usable) > (XEN) [00000000c6510000, 00000000c68c6fff] (reserved) > (XEN) [00000000c68c7000, 00000000d9867fff] (usable) > (XEN) [00000000d9868000, 00000000d98f1fff] (reserved) > (XEN) [00000000d98f2000, 00000000d991bfff] (ACPI data) > (XEN) [00000000d991c000, 00000000d9a06fff] (ACPI NVS) > (XEN) [00000000d9a07000, 00000000d9ffefff] (reserved) > (XEN) [00000000d9fff000, 00000000d9ffffff] (usable) > (XEN) [00000000dc000000, 00000000de1fffff] (reserved) > (XEN) [00000000f8000000, 00000000fbffffff] (reserved) > (XEN) [00000000fec00000, 00000000fec00fff] (reserved) > (XEN) [00000000fed00000, 00000000fed03fff] (reserved) > (XEN) [00000000fed1c000, 00000000fed1ffff] (reserved) > (XEN) [00000000fee00000, 00000000fee00fff] (reserved) > (XEN) [00000000ff000000, 00000000ffffffff] (reserved) > (XEN) [0000000100000000, 000000041fdfffff] (usable) > (XEN) ACPI: RSDP D9901298, 0024 (r2 HPQOEM) > (XEN) ACPI: XSDT D99012BC, 00B4 (r1 HPQOEM SLIC-BPC 20170509 AMI 10013) > (XEN) ACPI: FACP D9910018, 010C (r5 HPQOEM SLIC-BPC 20170509 AMI 10013) > (XEN) ACPI: DSDT D99021D0, DE46 (r2 HPQOEM SLIC-BPC 1 INTL 20091112) > (XEN) ACPI: FACS D9A05080, 0040 > (XEN) ACPI: APIC D9910128, 0072 (r3 HPQOEM SLIC-BPC 20170509 AMI 10013) > (XEN) ACPI: FPDT D99101A0, 0044 (r1 HPQOEM SLIC-BPC 20170509 AMI 10013) > (XEN) ACPI: SSDT D99101E8, 0539 (r1 PmRef Cpu0Ist 3000 INTL 20120711) > (XEN) ACPI: SSDT D9910728, 0AD8 (r1 PmRef CpuPm 3000 INTL 20120711) > (XEN) ACPI: SSDT D9911200, 01C7 (r1 PmRef LakeTiny 3000 INTL 20120711) > (XEN) ACPI: MCFG D99113C8, 003C (r1 HPQOEM SLIC-BPC 20170509 MSFT 97) > (XEN) ACPI: HPET D9911408, 0038 (r1 HPQOEM SLIC-BPC 20170509 AMI. 5) > (XEN) ACPI: SSDT D9911440, 036D (r1 SataRe SataTabl 1000 INTL 20120711) > (XEN) ACPI: SSDT D99117B0, 348C (r1 SaSsdt SaSsdt 3000 INTL 20091112) > (XEN) ACPI: SSDT D9914C40, 668F (r1 COMPAQ WMI 1 MSFT 3000001) > (XEN) ACPI: SLIC D991B2D0, 0176 (r1 HPQOEM SLIC-BPC 1 0) > (XEN) ACPI: MSDM D991B448, 0055 (r3 HPQOEM SLIC-BPC 20170509 HPQ 10013) > (XEN) ACPI: ASF! D991B4A0, 00A5 (r32 INTEL HCG 1 TFSM F4240) > (XEN) ACPI: TCPA D991B548, 0032 (r2 APTIO4 NAPAASF 1 MSFT 1000013) > (XEN) ACPI: BGRT D991B580, 0038 (r0 HPQOEM SLIC-BPC 20170509 AMI 10013) > (XEN) ACPI: DMAR D991B5B8, 00B8 (r1 INTEL HSW 1 INTL 1) > (XEN) ACPI: WPBT D9901370, 0034 (r1 ABT-NT ABT-WPBT 1 ABTW 20120402) > (XEN) System RAM: 16274MB (16664864kB) > (XEN) No NUMA configuration found > (XEN) Faking a node at 0000000000000000-000000041fe00000 > (XEN) Domain heap initialised > (XEN) SMBIOS 2.7 present. > (XEN) DMI 2.7 present. > (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 3f > (XEN) PCI: MCFG area at f8000000 reserved in E820 > (XEN) PCI: Using MCFG for segment 0000 bus 00-3f > (XEN) [VT-D]Host address width 39 > (XEN) [VT-D]found ACPI_DMAR_DRHD: > (XEN) [VT-D] dmaru->address = fed90000 > (XEN) [VT-D]drhd->address = fed90000 iommu->reg = ffff82c000209000 > (XEN) [VT-D]cap = c0000020660462 ecap = f0101a > (XEN) [VT-D] endpoint: 0000:00:02.0 > (XEN) [VT-D]found ACPI_DMAR_DRHD: > (XEN) [VT-D] dmaru->address = fed91000 > (XEN) [VT-D]drhd->address = fed91000 iommu->reg = ffff82c00020b000 > (XEN) [VT-D]cap = d2008020660462 ecap = f010da > (XEN) [VT-D] IOAPIC: 0000:f0:1f.0 > (XEN) [VT-D] MSI HPET: 0000:f0:0f.0 > (XEN) [VT-D] flags: INCLUDE_ALL > (XEN) [VT-D]found ACPI_DMAR_RMRR: > (XEN) [VT-D] endpoint: 0000:00:1d.0 > (XEN) [VT-D] endpoint: 0000:00:1a.0 > (XEN) [VT-D] endpoint: 0000:00:14.0 > (XEN) [VT-D]drivers/passthrough/vtd/dmar.c:610: RMRR: [d9888000,d9894fff] > (XEN) [VT-D]found ACPI_DMAR_RMRR: > (XEN) [VT-D] endpoint: 0000:00:02.0 > (XEN) [VT-D]drivers/passthrough/vtd/dmar.c:610: RMRR: [dc000000,de1fffff] > (XEN) Using APIC driver default > (XEN) ACPI: PM-Timer IO Port: 0x408 (24 bits) > (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] > (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] > (XEN) ACPI: 32/64X FACS address mismatch in FADT - d9a05080/0000000000000000, using 32 > (XEN) ACPI: wakeup_vec[d9a0508c], vec_size[20] > (XEN) ACPI: Local APIC address 0xfee00000 > (XEN) ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0]) > (XEN) IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23 > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > (XEN) ACPI: IRQ0 used by override. > (XEN) ACPI: IRQ2 used by override. > (XEN) ACPI: IRQ9 used by override. > (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 > (XEN) ACPI: BGRT: invalidating v1 image at 0xcbc74018 > (XEN) Using ACPI (MADT) for SMP configuration information > (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs) > (XEN) IRQ limits: 24 GSI, 808 MSI/MSI-X > (XEN) [VT-D]drivers/passthrough/vtd/qinval.c:520: QI: using 256-entry ring(s) > (XEN) Switched to APIC driver x2apic_mixed > (XEN) arch/x86/i8259.c:384: PIC aliasing mask: 1c > (XEN) CPU0: 800 ... 3400 MHz > (XEN) xstate: size: 0x340 and states: 0x7 > (XEN) arch/x86/cpu/mcheck/mce_intel.c:773: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, CMCI > (XEN) CPU0: Intel machine check reporting enabled > (XEN) Speculative mitigation facilities: > (XEN) Hardware hints: > (XEN) Hardware features: > (XEN) Compiled-in support: INDIRECT_THUNK RETURN_THUNK SHADOW_PAGING HARDEN_ARRAY HARDEN_BRANCH HARDEN_GUEST_ACCESS HARDEN_LOCK > (XEN) Xen settings: BTI-Thunk: RETPOLINE, SPEC_CTRL: No, Other: BRANCH_HARDEN > (XEN) L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe address 8000000000 > (XEN) Support for HVM VMs: RSB EAGER_FPU > (XEN) Support for PV VMs: EAGER_FPU > (XEN) XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID) > (XEN) PV L1TF shadowing: Dom0 disabled, DomU enabled > (XEN) Using scheduler: SMP Credit Scheduler rev2 (credit2) > (XEN) Initializing Credit2 scheduler > (XEN) load_precision_shift: 18 > (XEN) load_window_shift: 30 > (XEN) underload_balance_tolerance: 0 > (XEN) overload_balance_tolerance: -3 > (XEN) runqueues arrangement: socket > (XEN) cap enforcement granularity: 10ms > (XEN) load tracking window length 1073741824 ns > (XEN) Using IDT event delivery > (XEN) arch/x86/time.c:495: PIT aliasing mask: 10 > (XEN) ----[ Xen-4.22-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[<ffff82d04064a6f8>] hpet_setup+0x6b/0x120 > (XEN) RFLAGS: 0000000000010082 CONTEXT: hypervisor > (XEN) rax: ffff82cffff3a000 rbx: 0000000000000000 rcx: 000000000000000c > (XEN) rdx: ffff82fffffffffe rsi: 8000000000000000 rdi: ffff8300c421fff8 > (XEN) rbp: ffff82d04065fd28 rsp: ffff82d04065fd18 r8: 0000000000000046 > (XEN) r9: ffff82d04092e180 r10: ffff82d04092e188 r11: 0000000000000010 > (XEN) r12: ffff82d04069c0c0 r13: ffff82d040666530 r14: ffff82d04092f0a8 > (XEN) r15: ffff82d04069c0d8 cr0: 000000008005003b cr4: 00000000001506e0 > (XEN) cr3: 00000000c4222000 cr2: ffff82cffff3a000 > (XEN) fsb: 0000000000000000 gsb: 0000000000000000 gss: 0000000000000000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 > (XEN) Xen code around <ffff82d04064a6f8> (hpet_setup+0x6b/0x120): > (XEN) 00 a0 f3 ff cf 82 ff ff <8b> 10 84 d2 0f 84 80 00 00 00 a1 04 a0 f3 ff cf > (XEN) Xen stack trace from rsp=ffff82d04065fd18: > (XEN) ffff82d040666530 ffff82d04092f0a8 ffff82d04065fd48 ffff82d04064963a > (XEN) ffff82d040666530 ffff82d04092f0a8 ffff82d04065fd78 ffff82d0406497c9 > (XEN) 0000000000000010 ffff82d04069c0c0 ffff82d040666530 ffff82d04092f0a8 > (XEN) ffff82d04065fdb8 ffff82d040649fef 0000000000000000 ffff82d04092f1a0 > (XEN) ffff82d04092f1a0 ffff82d040808208 0000000000000002 ffff83041a9b8000 > (XEN) ffff82d04065ff00 ffff82d0406449d2 ffff82d04069b020 000000041a9c8000 > (XEN) ffff82d04069b050 0000000100000000 ffff82d04093ff08 0000000001102000 > (XEN) ffff82d040696014 ffff82d04069aff0 000000041dfe5400 0000000000100000 > (XEN) 0000000000000000 0000050000000000 ffffffff00000163 000000000041fe00 > (XEN) 0000000000000019 0000000601000000 00000001ffffffff ffff82d04065ff08 > (XEN) ffff82d04069b020 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000800000000 000000010000006e > (XEN) 0000000000000003 00000000000002f8 ffff82d040927000 ffff82d040927000 > (XEN) ffffffffffffffff 0000000000000000 00000000cbcffe58 0000000000000000 > (XEN) 00000000c4068acb 00000000c29e2620 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > (XEN) Xen call trace: > (XEN) [<ffff82d04064a6f8>] R hpet_setup+0x6b/0x120 > (XEN) [<ffff82d04064963a>] F arch/x86/time.#init_hpet+0x30/0x119 > (XEN) [<ffff82d0406497c9>] F arch/x86/time.#try_platform_timer+0x17/0x12b > (XEN) [<ffff82d040649fef>] F early_time_init+0x1e7/0x2ec > (XEN) [<ffff82d0406449d2>] F __start_xen+0x1f2e/0x25b1 > (XEN) > (XEN) Pagetable walk from ffff82cffff3a000: > (XEN) L4[0x105] = 00000000c4221063 ffffffffffffffff > (XEN) L3[0x13f] = 00000000c421f063 ffffffffffffffff > (XEN) L2[0x1ff] = 00000000c432b063 ffffffffffffffff > (XEN) L1[0x13a] = 80000000fed00173 ffffffffffffffff > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) FATAL PAGE FAULT > (XEN) [error_code=0009] > (XEN) Faulting linear address: ffff82cffff3a000 > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG. With "require NX", I don't get anything on the serial console, and VGA gives a black screen after loading Xen. I'm not sure what's going on in this case. If "DEP" is enabled in firmware, there are no issues so far. Teddy -- | Vates XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 27/01/2026 11:23 am, Teddy Astie wrote: > Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >> I was hoping this to be a patch or two, but it got out of hand... >> >> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >> >> The branch has one extra patch to fake up the firmware settings being set to >> Gitlab CI, not included in this series. >> >> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >> did the AMD adjustment mostly because I needed it to test the correctness of >> the prior cleanup. >> >> The final 4 patches are tangential cleanup which I've kept out of the prior >> work in case we wish to backport it. Everything prior is relevant to >> untangling, and mostly for the benefit of the AMD side. >> >> The early patches are hopefully non-controvertial. Later patches are a little >> more RFC, and in need of further testing. >> >> <snip> >> > Tested on a Intel machine with "DEP" disabled, and "Require NX support" > disabled, I get a pagefault in hpet code From above: > Julien: This ought to suitable to rebase your cleanup on to. This is cleanup only. I've not got the bugfixes for EFI boot yet, so the behaviour you see is still expected for now. Although, thinking about it, it might be better if I try to merge the two series, so everyone can test the end result. Thoughts? >> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >> (XEN) re-enabled NX (Execute Disable) protection >> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >> (XEN) BSP microcode revision: 0x0000001a >> (XEN) microcode: Bad data in container >> (XEN) Microcode: Parse error -22 As a tangent, what's going on here? This is the first time I've seen the error outside of my own testing. Is it a container you expect to be good, or some leftovers on a test machine? ~Andrew
Le 27/01/2026 à 12:39, Andrew Cooper a écrit : > On 27/01/2026 11:23 am, Teddy Astie wrote: >> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>> I was hoping this to be a patch or two, but it got out of hand... >>> >>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>> >>> The branch has one extra patch to fake up the firmware settings being set to >>> Gitlab CI, not included in this series. >>> >>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>> did the AMD adjustment mostly because I needed it to test the correctness of >>> the prior cleanup. >>> >>> The final 4 patches are tangential cleanup which I've kept out of the prior >>> work in case we wish to backport it. Everything prior is relevant to >>> untangling, and mostly for the benefit of the AMD side. >>> >>> The early patches are hopefully non-controvertial. Later patches are a little >>> more RFC, and in need of further testing. >>> >>> <snip> >>> >> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >> disabled, I get a pagefault in hpet code > > From above: > >> Julien: This ought to suitable to rebase your cleanup on to. > > This is cleanup only. I've not got the bugfixes for EFI boot yet, so > the behaviour you see is still expected for now. > > Although, thinking about it, it might be better if I try to merge the > two series, so everyone can test the end result. > > Thoughts? > +1 >>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>> (XEN) re-enabled NX (Execute Disable) protection >>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>> (XEN) BSP microcode revision: 0x0000001a >>> (XEN) microcode: Bad data in container >>> (XEN) Microcode: Parse error -22 > > As a tangent, what's going on here? > > This is the first time I've seen the error outside of my own testing. > Is it a container you expect to be good, or some leftovers on a test > machine? > I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). Many distros ship microcode in a single CPIO image with e.g "kernel/x86/microcode/GenuineIntel.bin" in it. > ~Andrew > -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
On 27/01/2026 12:09 pm, Teddy Astie wrote: > Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >> On 27/01/2026 11:23 am, Teddy Astie wrote: >>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>> I was hoping this to be a patch or two, but it got out of hand... >>>> >>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>> >>>> The branch has one extra patch to fake up the firmware settings being set to >>>> Gitlab CI, not included in this series. >>>> >>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>> the prior cleanup. >>>> >>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>> work in case we wish to backport it. Everything prior is relevant to >>>> untangling, and mostly for the benefit of the AMD side. >>>> >>>> The early patches are hopefully non-controvertial. Later patches are a little >>>> more RFC, and in need of further testing. >>>> >>>> <snip> >>>> >>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>> disabled, I get a pagefault in hpet code >> From above: >> >>> Julien: This ought to suitable to rebase your cleanup on to. >> This is cleanup only. I've not got the bugfixes for EFI boot yet, so >> the behaviour you see is still expected for now. >> >> Although, thinking about it, it might be better if I try to merge the >> two series, so everyone can test the end result. >> >> Thoughts? >> > +1 > >>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>> (XEN) re-enabled NX (Execute Disable) protection >>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>> (XEN) BSP microcode revision: 0x0000001a >>>> (XEN) microcode: Bad data in container >>>> (XEN) Microcode: Parse error -22 >> As a tangent, what's going on here? >> >> This is the first time I've seen the error outside of my own testing. >> Is it a container you expect to be good, or some leftovers on a test >> machine? >> > I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode > package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). > > Many distros ship microcode in a single CPIO image with e.g > "kernel/x86/microcode/GenuineIntel.bin" in it. Ah, that's a known thing that doesn't work and has never been addressed. People have been complaining for years, but not on xen-devel. It's also the subject of a documentation fix that is still pending (and now needs yet another rebase). https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com Now that the ucode boot module handling is clean, we can probably try both a CPIO and raw probe when given a fixed module. ~Andrew
On 27.01.2026 13:29, Andrew Cooper wrote: > On 27/01/2026 12:09 pm, Teddy Astie wrote: >> Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >>> On 27/01/2026 11:23 am, Teddy Astie wrote: >>>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>>> I was hoping this to be a patch or two, but it got out of hand... >>>>> >>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>>> >>>>> The branch has one extra patch to fake up the firmware settings being set to >>>>> Gitlab CI, not included in this series. >>>>> >>>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>>> the prior cleanup. >>>>> >>>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>>> work in case we wish to backport it. Everything prior is relevant to >>>>> untangling, and mostly for the benefit of the AMD side. >>>>> >>>>> The early patches are hopefully non-controvertial. Later patches are a little >>>>> more RFC, and in need of further testing. >>>>> >>>>> <snip> >>>>> >>>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>>> disabled, I get a pagefault in hpet code >>> From above: >>> >>>> Julien: This ought to suitable to rebase your cleanup on to. >>> This is cleanup only. I've not got the bugfixes for EFI boot yet, so >>> the behaviour you see is still expected for now. >>> >>> Although, thinking about it, it might be better if I try to merge the >>> two series, so everyone can test the end result. >>> >>> Thoughts? >>> >> +1 >> >>>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>>> (XEN) re-enabled NX (Execute Disable) protection >>>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>>> (XEN) BSP microcode revision: 0x0000001a >>>>> (XEN) microcode: Bad data in container >>>>> (XEN) Microcode: Parse error -22 >>> As a tangent, what's going on here? >>> >>> This is the first time I've seen the error outside of my own testing. >>> Is it a container you expect to be good, or some leftovers on a test >>> machine? >>> >> I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode >> package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). >> >> Many distros ship microcode in a single CPIO image with e.g >> "kernel/x86/microcode/GenuineIntel.bin" in it. > > Ah, that's a known thing that doesn't work and has never been > addressed. People have been complaining for years, but not on xen-devel. > > It's also the subject of a documentation fix that is still pending (and > now needs yet another rebase). > https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com > > Now that the ucode boot module handling is clean, we can probably try > both a CPIO and raw probe when given a fixed module. What does "raw probe" here mean? "ucode=" with a proper ucode blob specified has always been working for me ... (In fact I don't think I ever really tried the "scan" approach.) Jan
On 27/01/2026 12:54 pm, Jan Beulich wrote: > On 27.01.2026 13:29, Andrew Cooper wrote: >> On 27/01/2026 12:09 pm, Teddy Astie wrote: >>> Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >>>> On 27/01/2026 11:23 am, Teddy Astie wrote: >>>>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>>>> I was hoping this to be a patch or two, but it got out of hand... >>>>>> >>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>>>> >>>>>> The branch has one extra patch to fake up the firmware settings being set to >>>>>> Gitlab CI, not included in this series. >>>>>> >>>>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>>>> the prior cleanup. >>>>>> >>>>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>>>> work in case we wish to backport it. Everything prior is relevant to >>>>>> untangling, and mostly for the benefit of the AMD side. >>>>>> >>>>>> The early patches are hopefully non-controvertial. Later patches are a little >>>>>> more RFC, and in need of further testing. >>>>>> >>>>>> <snip> >>>>>> >>>>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>>>> disabled, I get a pagefault in hpet code >>>> From above: >>>> >>>>> Julien: This ought to suitable to rebase your cleanup on to. >>>> This is cleanup only. I've not got the bugfixes for EFI boot yet, so >>>> the behaviour you see is still expected for now. >>>> >>>> Although, thinking about it, it might be better if I try to merge the >>>> two series, so everyone can test the end result. >>>> >>>> Thoughts? >>>> >>> +1 >>> >>>>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>>>> (XEN) re-enabled NX (Execute Disable) protection >>>>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>>>> (XEN) BSP microcode revision: 0x0000001a >>>>>> (XEN) microcode: Bad data in container >>>>>> (XEN) Microcode: Parse error -22 >>>> As a tangent, what's going on here? >>>> >>>> This is the first time I've seen the error outside of my own testing. >>>> Is it a container you expect to be good, or some leftovers on a test >>>> machine? >>>> >>> I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode >>> package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). >>> >>> Many distros ship microcode in a single CPIO image with e.g >>> "kernel/x86/microcode/GenuineIntel.bin" in it. >> Ah, that's a known thing that doesn't work and has never been >> addressed. People have been complaining for years, but not on xen-devel. >> >> It's also the subject of a documentation fix that is still pending (and >> now needs yet another rebase). >> https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com >> >> Now that the ucode boot module handling is clean, we can probably try >> both a CPIO and raw probe when given a fixed module. > What does "raw probe" here mean? "ucode=" with a proper ucode blob specified > has always been working for me ... (In fact I don't think I ever really tried > the "scan" approach.) This isn't (really) about scan. What both Arch (where I noticed this complaint first) and Alpine do is pass: ucode=CPIO(GenuineIntel.bin, AuthenticAMD.bin) as would otherwise be prepended to the initrd, and Xen rejects this because it's not a valid vendor blob. What I'm thinking of is something like this: diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c index 9e055b6f9805..82ddb5e9a6d2 100644 --- a/xen/arch/x86/cpu/microcode/core.c +++ b/xen/arch/x86/cpu/microcode/core.c @@ -847,6 +847,11 @@ static int __init early_microcode_load(struct boot_info *bi) idx, size); return -ENODEV; } + + if ( is_cpio(data) && + find_cpio_data(ucode_ops.cpio_path, data, size) ) + ...; + goto found; } where we'd accept both raw and CPIO-wrapped blobs any time we nominate an explicit module (whether via Grub, or implicitly via EFI). ~Andrew
On 27.01.2026 14:02, Andrew Cooper wrote: > On 27/01/2026 12:54 pm, Jan Beulich wrote: >> On 27.01.2026 13:29, Andrew Cooper wrote: >>> On 27/01/2026 12:09 pm, Teddy Astie wrote: >>>> Le 27/01/2026 à 12:39, Andrew Cooper a écrit : >>>>> On 27/01/2026 11:23 am, Teddy Astie wrote: >>>>>> Le 26/01/2026 à 18:56, Andrew Cooper a écrit : >>>>>>> I was hoping this to be a patch or two, but it got out of hand... >>>>>>> >>>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2287078891 >>>>>>> https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/nx >>>>>>> >>>>>>> The branch has one extra patch to fake up the firmware settings being set to >>>>>>> Gitlab CI, not included in this series. >>>>>>> >>>>>>> Julien: This ought to suitable to rebase your cleanup on to. In the end, I >>>>>>> did the AMD adjustment mostly because I needed it to test the correctness of >>>>>>> the prior cleanup. >>>>>>> >>>>>>> The final 4 patches are tangential cleanup which I've kept out of the prior >>>>>>> work in case we wish to backport it. Everything prior is relevant to >>>>>>> untangling, and mostly for the benefit of the AMD side. >>>>>>> >>>>>>> The early patches are hopefully non-controvertial. Later patches are a little >>>>>>> more RFC, and in need of further testing. >>>>>>> >>>>>>> <snip> >>>>>>> >>>>>> Tested on a Intel machine with "DEP" disabled, and "Require NX support" >>>>>> disabled, I get a pagefault in hpet code >>>>> From above: >>>>> >>>>>> Julien: This ought to suitable to rebase your cleanup on to. >>>>> This is cleanup only. I've not got the bugfixes for EFI boot yet, so >>>>> the behaviour you see is still expected for now. >>>>> >>>>> Although, thinking about it, it might be better if I try to merge the >>>>> two series, so everyone can test the end result. >>>>> >>>>> Thoughts? >>>>> >>>> +1 >>>> >>>>>>> (XEN) Xen version 4.22-unstable (tsnake41@(none)) (gcc (Alpine 15.2.0) 15.2.0) debug=y Tue Jan 27 12:06:46 CET 2026 >>>>>>> (XEN) Latest ChangeSet: Mon Jan 26 17:53:45 2026 +0000 git:6491616ddd >>>>>>> (XEN) build-id: 035024497a4cadebf9e5a2ded61f63ac >>>>>>> (XEN) re-enabled NX (Execute Disable) protection >>>>>>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) >>>>>>> (XEN) BSP microcode revision: 0x0000001a >>>>>>> (XEN) microcode: Bad data in container >>>>>>> (XEN) Microcode: Parse error -22 >>>>> As a tangent, what's going on here? >>>>> >>>>> This is the first time I've seen the error outside of my own testing. >>>>> Is it a container you expect to be good, or some leftovers on a test >>>>> machine? >>>>> >>>> I'm trying to load a Intel ucode (taken from Alpine Linux intel-ucode >>>> package) using `ucode=intel-ucode.img` in xen.cfg (UEFI direct boot). >>>> >>>> Many distros ship microcode in a single CPIO image with e.g >>>> "kernel/x86/microcode/GenuineIntel.bin" in it. >>> Ah, that's a known thing that doesn't work and has never been >>> addressed. People have been complaining for years, but not on xen-devel. >>> >>> It's also the subject of a documentation fix that is still pending (and >>> now needs yet another rebase). >>> https://lore.kernel.org/xen-devel/20251215153245.2675388-1-andrew.cooper3@citrix.com >>> >>> Now that the ucode boot module handling is clean, we can probably try >>> both a CPIO and raw probe when given a fixed module. >> What does "raw probe" here mean? "ucode=" with a proper ucode blob specified >> has always been working for me ... (In fact I don't think I ever really tried >> the "scan" approach.) > > This isn't (really) about scan. > > What both Arch (where I noticed this complaint first) and Alpine do is pass: > > ucode=CPIO(GenuineIntel.bin, AuthenticAMD.bin) > > as would otherwise be prepended to the initrd, and Xen rejects this > because it's not a valid vendor blob. > > What I'm thinking of is something like this: > > diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c > index 9e055b6f9805..82ddb5e9a6d2 100644 > --- a/xen/arch/x86/cpu/microcode/core.c > +++ b/xen/arch/x86/cpu/microcode/core.c > @@ -847,6 +847,11 @@ static int __init early_microcode_load(struct boot_info *bi) > idx, size); > return -ENODEV; > } > + > + if ( is_cpio(data) && > + find_cpio_data(ucode_ops.cpio_path, data, size) ) > + ...; > + > goto found; > } > > > > where we'd accept both raw and CPIO-wrapped blobs any time we nominate > an explicit module (whether via Grub, or implicitly via EFI). Ah, I see. Jan
© 2016 - 2026 Red Hat, Inc.