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.) Jan
