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

On Tue, 12 May 2026, Borislav Petkov wrote:
>
> On Tue, May 12, 2026 at 09:12:25AM +0200, Ahmed S. Darwish wrote:
> > So the min_t()'s intent is just to be defensive against hardware surprises.
>
> But when you read l0->max_std_leaf, you always get the current, highest base
> level. So there's nothing to protect against.
>
> Or am I missing something?
>

So, let's imagine the following cases of cached CPUID tables.  The changes
to the new max CPUID are due to MSR writes.

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

This is accomplished the logic:

	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);

Since it will only begin filling things from CPUID(0x3).

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

This is accomplished the logic:

	rescan_from = min_t(int, l0->max_std_leaf, c->cpuid_level) + 1;
	cpuid_refresh_range(c, rescan_from, CPUID_BASE_END);

Since it will zero CPUID(0x3) and CPUID(0x4), as it is part of the
cpuid_refresh_range() logic.

And that's what I meant that the min_t() logic handles hardware surprises:
it continues to work, regardless if the new max CPUID is higher or lower
after the MSR write.

I guess I should've put this min_t() logic in its own cpuid_parser.c
function, with proper comments about this.  There were only two cases for
it, this patch and patch 13/90, but two call sites are enough for a parser
API function.

Thanks,
Ahmed