Re: x86 CPUID mutable return values

[Christian Ludloff]

On Mon, Sep 21, 2026 at 11:32 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 9/21/26 11:36, Christian Ludloff wrote:
> > Q for Intel: is MSR FEATURE_CONFIG 0x13C bit 1 expected
> > to affect CPUID 1.ECX.25 and 7.0.ECX.9 and 19.EBX.0/2, or
> > just just a subset of them? Also, what about PCLMUL?
>
> Are you looking to document architecture or implementation here?

Just the reality of mutable CPUID return values.

Because it matters. When trying to cache them.

> I poked around on a few pieces of hardware I have within reach and all
> of them have the MSR FEATURE_CONFIG lock bit set and the disable bit clear.
>
> # rdmsr -a 0x13C
> 1
> 1
> 1
> 1
> ...
>
> In practice, I suspect the AESNI CPUID bits are immutable.

If the LOCK bit is set. Which is recommended.

But apparently not always done. No surprises.

> FEATURE_CONFIG's definitions also looks model specific in the spots I see it in the SDM. They're also not identical, interestingly enough.

While the verbiage across documents mutated
a bit over time, the functionality of DISABLE as
well as LOCK seems to have been immutable
ever since WSM and GLM introduced them.

Based on some experiments, I think that VAES
does follow AES (i.e. is mutable as well), while
KL and PCLMUL do not (i.e. are immutable) –
so that's what I am seeking confirmation for.

> Honestly, FEATURE_CONFIG looks more like something that should have been in the BIOS writers' guide rather than the SDM.

I for one appreciate that the SDM attempts to
provide a list of mutable CPUID return values
and that it has the FEATURE_CONFIG MSR.

After all... the most recent public Intel BWG is
more than 30 years old by now [aka P6 days],
and https://en.wikipedia.org/wiki/Appendix_H
was a thing that also happened back then.  :)

PS: Should Linux boot check/fix that LOCK?

--
C.