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/[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).
Ah, I see. Jan
