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

[Borislav Petkov]

On Sat, Sep 12, 2026 at 12:08:06AM +0000, Chang S. Bae wrote:
> Hi all,
> 
> This series enables another Intel microcode loading feature.
> 
> While this initial posting is marked with RFC, it is also expected to
> provide patches to the people who are interested in testing/using this
> feature. Tested-by is anticipated from that end.
> 
> So, x86 maintainers, feel free to ignore this round. Having said that,
> feedback will be appreciated and always welcomed.
> 
> == 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?

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

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

> == 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?

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

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette