Re: [PATCH v8 3/7] crypto/ccp: Disable CPU hotplug while SNP is active

[Kalra, Ashish]

On 6/19/2026 3:51 PM, Kalra, Ashish wrote:
> 
> On 6/18/2026 4:35 PM, Dave Hansen wrote:
>> On 6/15/26 12:49, Ashish Kalra wrote:
>>> +	/*
>>> +	 * Disable CPU hotplug while SNP is active.  Guard against stacking
>>> +	 * the disable count: the legacy SNP_SHUTDOWN_EX path clears
>>> +	 * snp_initialized without re-enabling hotplug, so this can run
>>> +	 * again while hotplug is already disabled.
>>> +	 */
>>> +	if (!snp_cpu_hotplug_disabled) {
>>> +		cpu_hotplug_disable();
>>> +		snp_cpu_hotplug_disabled = true;
>>> +	}
>>
>> This seems like a hack, guys.
>>
>> cpu_hotplug_disable() seems like more of a temporary lock than enforcing
>> basically permanent system state.
>>
>> This seems like it would be better implemented by registering a CPU
>> hotplug callback and then refusing to offline if sev->snp_initialized is
>> set.
>>
>> snp_setup_rmpopt() can be run any time, right? It doesn't need to be
>> after sev->snp_initialized=1.
> 
> Yes, snp_setup_rmpopt() doesn't depend on snp_initialized. Programming RMPOPT_BASE only needs
> the CPU online and the system rmpopt_capable.

After feedback from Tom, adding here that RMPOPT_BASE (RMPOPT_EN) can only be set if 
SNP and SegmentedRMP are enabled. 

Therefore, we can only call snp_setup_rmpopt() after snp_prepare() has enabled SNP in
__sev_snp_init_locked() (CCP module).

Additionally, as SNP_INIT, clears the RMPOPT table contents to 0, therefore we call it
after SNP_INIT_EX.
 
Thanks,
Ashish
 
> 
> Based on Dave's feedback, i am going to drop this cpu_hotplug_disable()/cpu_hotplug_enable()
> and instead implementing and registering the CPU hotplug callback and then refusing to go offline
> if SNP is enabled, unless anyone else here has a different thought/suggestion.
> 
> Thanks,
> Ashish