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
