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/[email protected] >> >> 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
