Re: [PATCH 2/5] x86/ucode: Abort parallel load early on any control thread error

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/10/2025 4:55 pm, Jan Beulich wrote:
> On 20.10.2025 15:19, Andrew Cooper wrote:
>> EIO is not the only error that ucode_ops.apply_microcode() can produce.
>> EINVAL, EEXISTS and ENXIO can be generated too, each of which mean that Xen 
>> is
>> unhappy in some way with the proposed blob.
> Yes, yet wasn't that the case already when the EIO check was added? Were we
> perhaps trying to deal with a certain level of asymmetry in the system? I
> think a little more is needed here, also to ...
>
>> Some of these can be bypassed with --force, which will cause the parallel 
>> load
>> to be attempted.
>>
>> Fixes: 5ed12565aa32 ("microcode: rendezvous CPUs in NMI handler and load 
>> ucode")
> ... justify there being a Fixes: tag. It would also seem possible that the
> check was intentional and correct at the time of introduction, but was
> rendered stale by some later change.

The parallel load logic more bugs than lines of code.  What hasn't
already been rewritten either has pending patches, or pending bugs
needing fixing.

I didn't care to check why it was limited to EIO at the time.  It's
definitely wrong.

But if you insist that I waste time doing so, at the time EIO was
introduced, both apply_microcode()'s could fail with -ENOENT for a NULL
pointer, -EINVAL for "patch isn't for this CPU".

I.e. it was definitely wrong at the time too.

~Andrew