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.