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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 23/10/2025 7:24 am, Jan Beulich wrote:
> 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?

If you mean CPU asymmetry, I'm going to argue this as a bugfix.  Some
Intel CPUs are known not to check the stepping, accept the wrong
microcode, and crash.  I have more patches to at least make this case
very obvious, but I need to get through some of the existing queue first.

If you mean revision asymmetry, nothing has really changed here.  The
parallel load is only started if a blob newer than the cache is found. 
If --force is used to override this check and load anyway, you also
won't get -EEXISTs out of apply_microcode().

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

I have rewritten most of microcode loading from scratch.  What hasn't
yet been rewritten is pending, with serious errors already identified
on-list and more still that haven't made it into public.

I would be further through if it had not taken an unreasonable amount of
effort to make the changes so far.  You refused my module changes
despite the blatant issues in the existing code, forcing me to
manoeuvrer them in via the boot_info changes (and in so doing discover
that module handling in general was even more broken than originally
realised).

The current pending series is in part stuck because I haven't had the
energy to tell you to stop trying to scope creep the work.

So yes, I was irritated at being asked to justify not breaking a thing
which has been thoroughly demonstrated to be broken.

>
> Nevertheless, considering that asymmetry is not something we really mean to
> care about:
>
> Acked-by: Jan Beulich <jbeulich@suse.com>

Thanks.

~Andrew