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.
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")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
---
xen/arch/x86/cpu/microcode/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/microcode/core.c b/xen/arch/x86/cpu/microcode/core.c
index 1b093bc98a58..2705bb43c97f 100644
--- a/xen/arch/x86/cpu/microcode/core.c
+++ b/xen/arch/x86/cpu/microcode/core.c
@@ -392,10 +392,10 @@ static int control_thread_fn(const struct microcode_patch *patch,
atomic_inc(&cpu_updated);
atomic_inc(&cpu_out);
- if ( ret == -EIO )
+ if ( ret )
{
printk(XENLOG_ERR
- "Late loading aborted: CPU%u failed to update ucode\n", cpu);
+ "Late loading aborted: CPU%u failed to update ucode: %d\n", cpu, ret);
goto out;
}
--
2.39.5
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.
Jan
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
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@suse.com>
Jan
> I.e. it was definitely wrong at the time too.
>
> ~Andrew
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
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
© 2016 - 2025 Red Hat, Inc.