x86 CPUID mutable return values

From: Christian Ludloff

Date: Mon Sep 21 2026 - 14:40:53 EST


Back in May I wrote...

> https://lore.kernel.org/lkml/CAKSQd8XM6p7TTVih9fg9fmUAkzNchPCT7B-6qzVuja=3hg_u+A@xxxxxxxxxxxxxx/
>
> When deciding what the code shall do for mutable CPUID bits,
> you really want to have an exhaustive list of events that trigger
> changes – think Intel SDM vol1 21.1.5 as a starting point; then
> made exhaustive for all events, for Intel and the other vendors.

I annotated https://www.sandpile.org/x86/cpuid.htm – you can
search for "mutable", to get a little over 70 hits.

I can mark AES and PCLMUL as well... pending confirmation:

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?

Q for AMD: is MSR DE_CFG 0xC001_1029 bit 16 expected to
affect just CPUID 1.ECX.25/1 and 7.0.ECX.10/9?

If there are more mutable bits or fields, then please speak up.

Ahmed – is there a proper way to reflect "mutable" in the db?

> (Besides on/off bits spread all over the place, microcode loads
> at runtime come to mind as... uhm... interesting...)

Presumably ucode loads should trigger a full CPUID re-read?

Last but not least, there was the case of the Rise mP6 config
leaves, i.e. CPUID, abused for applying config settings. Look
at https://www.sandpile.org/x86/cpuid.htm#leaf_6363_4523h
for basic information – it's unclear what effect these had... for
all we know, it could have been CPUID... affecting... itself...?

Ahmed – I don't know how you want to reflect that in the db?

--
C.