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. ~Andrew
