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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.10.2025 23:46, Andrew Cooper wrote:
> 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.

Hmm. You may have memorized all the details. I haven't. Instead I need
pointers to where aspects were discussed that matter here. It still
feels odd to me that my (implicit) request to supply such is deemed a
waste of time.

As to me refusing changes (here or elsewhere): In case it hadn't become
obvious to you, no matter whether it's your or my (or actually also
other people's) changes - when things get stuck, they almost always get
stuck at your end. You simply don't get back. When it's your changes -
I can be convinced. But if I raise questions or even objections, that
means I also _want_ to be convinced (rather than silently giving in).
That requires taking the time to respond accordingly, yes. When it's my
patches, I do take the time (often in vein, as a response then never
appears). When it's your patches, you will want to accept that you need
to take the time then as well, in order to make your work make progress.
Simply coming back months or years later claiming I (or somebody else)
blocked some of your work is at best a very subjective view of the world,
imo at least.

Jan