Re: [PATCH v3 1/6] x86/sme: Use percpu boolean to control wbinvd during kexec

["Huang, Kai" <kai.huang@intel.com>]

On Sat, 2025-06-28 at 12:04 -0500, Tom Lendacky wrote:
> On 6/28/25 07:50, Borislav Petkov wrote:
> > On Thu, Jun 26, 2025 at 10:48:47PM +1200, Kai Huang wrote:
> > 
> 
> > > +	 * support SME. This provides support for performing a successful
> > > +	 * kexec when going from SME inactive to SME active (or vice-versa).
> > > +	 *
> > > +	 * The cache must be cleared so that if there are entries with the
> > > +	 * same physical address, both with and without the encryption bit,
> > > +	 * they don't race each other when flushed and potentially end up
> > > +	 * with the wrong entry being committed to memory.
> > > +	 *
> > > +	 * Test the CPUID bit directly because the machine might've cleared
> > > +	 * X86_FEATURE_SME due to cmdline options.
> > 
> > Where?
> > 
> > That same function does the clearing later...
> 
> I think he means that if this function does clear X86_FEATURE_SME during
> the BSP boot, then when the APs boot they won't see the feature set, so
> you have to check the CPUID information directly. So maybe that can better
> worded.
> 
> I did verify that booting with mem_encrypt=off will start with
> X86_FEATURE_SME set, the BSP will clear it and then all APs will not see
> it set after that.

I think I actually mean it could be cleared by 'clearcpuid' commandline. :-)

IIUC the AP taking out feature bits that are not set in BSP happens at the
end of identify_cpu(), so it happens after early_detect_mem_encrypt(), which
is called in init_amd().

So the mem_encrypt=off will eventually clear the X86_FEATURE_SME, but when 
early_detect_mem_encrypt() for BSP and AP, IIRC it will still see the
X86_FEATURE_SME bit.

But IIUC the 'clearcpuid' commandline could still just make
early_detect_mem_encrypt() unable to see X86_FEATURE_SME bit on the SME
capable platform.