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

[Jan Beulich <jbeulich@xxxxxxxx>]

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/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.

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