Re: [PATCH 00/16] x86/cpu: Cleanup for NX adjustments

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@xxxxxxxxxx

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