Re: [PATCH RFC v1 0/8] x86/microcode: Enable uniform feature

[Chang S. Bae]

On 9/15/2026 5:45 PM, Borislav Petkov wrote:
> > == Introduction ==
> >
> > Traditionally, a single trigger updates a core-scoped microcode, which
> > thus requires executing WRMSR0x79 on every core. This also means that
> > there is a possibility to load different microcode patches between cores.
>
> Are you talking about heterogeneous cores?

No. On a SMP system, this should be disallowed. The software does not 
leave different microcode revisions running on different CPUs. If ever 
happens, the system can become unstable depending on the differences 
between the revisions.

So this is just about the loading mechanism itself which has been a gap 
in theory to microcode people. It was intended to bring up their 
motivation which I thought interesting as hearing. But the introduction 
made this unnecessarily confusing.

> > Despite this fact, the kernel currently enforces loading the same image
> > across the CPUs.
> >
> > This uniform microcode conceptually eliminates a chance of running a
> > different microcode within a scope of CPUs. From the loader perspective,
> > the uniform feature extends the loading scope to a larger number of cores
> > than one core.
>
> What does that even mean?
>
> You want to avoid loading different revisions on different cores, you want to
> support heterogeneous cores where you must load different patches, something
> else?

The starter seems to have done a really poor job here as seen implying
heterogeneous cores even, which is actually the opposite to what the 
uniform loading is trying to achieve, that is avoiding different 
revisions being loaded between cores.

Let me step back here. It looks rather clear that the introduction just 
stays in a very brief, something like in the spec.

> > A few points worth calling out about the feature:
> >
> >    * The CPU enumerates the update scope such as package-wide or system-
> >      wide, depending on the implementation. The scope is advertised
> >      via MSR and isn't programmable.
> >
> >    * The scope reduces the number of triggers, whereas staging primarily
> >      reduces the amount of work under the WRMSR window. Unlike staging,
> >      uniform loading is applicable to both early- and late-loading paths.
> >
> >    * For early loading, only the parallel CPU bringup is relevant. In the
> >      legacy serial bringup, once the first CPU in a scope completes the
> >      update, subsequent CPUs will observe the updated revision so skip
> >      WRMSR0x79.
> >
> >    * Staging introduced a new loading process. But uniform loading extends
> >      the semantics of the existing flow. Software that assumes the legacy
> >      scope remains supported. The next section discusses this
> >      compatibility aspect in more detail.
>
> I am more confused than I was before. I have no idea what uniform loading is.

Okay, sorry about that. I guess mentioning staging is just distracting, 
first and mentioning its applicability at this point may distract 
readers, too.

> > == Backward Compatibility ==
> >
> > Older kernels assume a per-core scope, being ignorant of the uniform
> > loading scope. So, they trigger loading via WRMSR0x79 on every core. And
> > the spec [1] has the following statement, in Section 2.4 "Uniform
> > Microcode Update":
> >
> >     NOTE [*]
> >     ... It is always allowed to load the update on more logical processors
> >     than necessary, which may result in unnecessary additional latency.
> >
> > So this means legacy kernels remain functional on uniform systems. To
> > provide more context, folks involved in the implementation agreed to
> > share additional implementation details with the community. Their
> > write-up is attached at the end of this cover letter.
>
> This sounds like you can load microcode on one logical CPU and that covers the
> whole socket? Or L3 slice?

Yes, loading on one logical CPU can cover the whole socket. That should 
be it in this introduction now I'm thinking...

> > == Appendix: Microcode Implementation Note ==
> >
> > The uniform update protocol is an optimization for boot/runtime microcode
> > update. It is backward compatible with existing microarchitecture of
> > core/thread scope update and any OS MCU drivers that rely on legacy
> > method of update.
> >
> > With uniform update, if multiple logical processors attempt to load an
> > update simultaneously, there is a race to an internal semaphore within
> > the microcode. The winner of the race assumes control of the update
> > process and sends an internal interrupt to all other threads (if only one
> > thread initiates the update, it is the winner by default).
> >
> > All other logical processors receive the internal interrupt at an
> > architectural instruction boundary and proceed to load the update under
> > the coordination of the winner. This ensures that the responding threads
> > load the update in a controlled manner while at a well-defined
> > architectural instruction boundary. If a higher priority interrupt or a
> > fault happens, all logical processors will see it either before the
> > microcode patch has been applied or after. In either case, all logical
> > processors will see the same microcode revision and nothing intermediate.
>
> I think you should lead with this, hm, weird requirement.
>
> So let's first, please, give a second try at explaining what this uniform
> thing is.

== Introduction ==

Intel introduces a new microcode loading feature - "uniform". With this 
feature, loading microcode from one logical CPU can update the whole 
socket or the entire system. The hardware implementation works as follows:

<-- paste the appendix here

Then, I guess I may say something about its side-effect which in fact is 
one of the motivation to support this feature. Could be combining next 
two sections into a summary before calling out review points.

Thanks,
Chang