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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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

~Andrew