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

[Jan Beulich <jbeulich@xxxxxxxx>]

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