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

[Borislav Petkov]

On Wed, May 13, 2026 at 06:06:37PM +0200, Ahmed S. Darwish wrote:
> That will break the clear_cpu_cap() just some few lines above it.  That is,
> it will reset all feature flags force set or unset by the kernel.

We do
	apply_forced_caps(c);

later in identify_cpu().

I think you mean whatever has done clear_cpu_cap() which doesn't use the
cpu_caps_cleared/set arrays.

> I'm sending another patch queue iteration shortly that have a new API
> function abstracting this min_t() logic in its own parser function, along
> with better documentation:
> 
>     https://lkml.kernel.org/agSfWTxs9pRPHJxl@lx-t490/

And I don't want to pay attention to which ranges I've parsed and which
I haven't. That's too fragile. I want to simply rescan the whole thing and be
up-to-date.

Also, what guarantees that this thing:

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

doesn't overwrite some unrelated ranges?

Also, in your example:


* 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

when you rescan and overwrite [2-9], what guarantees that you don't overwrite
an already set or cleared bit in those new leafs, say in leaf 5?

Neither set_cpu_cap() nor clear_cpu_cap() pay attention to the max base leaf
value?

IOW, I *think* we want to be on the safe side and reread *only* the leaf we
disabled.

I guess we need to know which leaf changes when a MSR bit is toggled and
rescan only that leaf alone.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette