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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.10.2025 21:28, Andrew Cooper wrote:
> 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".

The latter fits my "trying to deal with a certain level of asymmetry" guess,
doesn't it?

And btw, why are you being so negative again? "Waste time" is a pretty clear
sign of you (once again) thinking that your view of the world is the only
possibly sensible one.

Nevertheless, considering that asymmetry is not something we really mean to
care about:

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan

> I.e. it was definitely wrong at the time too.
> 
> ~Andrew