Re: [PATCH v6 10/90] x86/cpu: Rescan CPUID table after disabling PSN

[Ahmed S. Darwish]

For completeness:

On Wed, 13 May 2026, Ahmed S. Darwish wrote:
>
> * First case:
>
>          leaf 0x0
> 	   leaf 0x1
> 	   leaf 0x2     <- Old max CPUID
> 	   leaf 0x3
> 	   leaf 0x4
> 	   leaf 0x5
> 	   leaf 0x6
> 	   leaf 0x7
> 	   leaf 0x9     <- *New* max CPUID
>
> => Here, the parser code needs to leave CPUID(0x0) and CPUID(0x1) untouched.
>
> That's especially true since CPUID(0x1) holds the backing for some
> X86_FEATURE words, other flags might be force set or unset, etc.  So we
> don't need to touch that not to corrupt the state of force-enabled or
> disabled X86_FEATURE bits.
>
> (Then, it needs to fill the table entries for CPUID(0x3) to CPUID(0x9), but
> that's obvious.)
>
...
>
> * Second case:
>
>          leaf 0x0
> 	   leaf 0x1
> 	   leaf 0x2     <- *New* max CPUID
> 	   leaf 0x3
> 	   leaf 0x4	<- Old max CPUID
>
> => Here, the parser will need to zero CPUID(0x3) and CPUID(0x4) entries.
>
> This is because the CPUID API query macros at <asm/cpuid/api.h> know the
> validity of each entry through its nr_entries flag:
>
> struct leaf_parse_info {
> 	unsigned int		nr_entries;
> };
>
> And without the zeroing of entries, the CPUID API will return invalid and
> stale values for CPUID(0x3) and CPUID(0x4), instead of returning the right
> value: NULL.
>

And similar to the first case, it will also need to keep the previously
cached CPUID(0x1) values intact, not to corrupt any previously force-set or
force-unset bits.

Thanks,
Ahmed