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

["Kalra, Ashish" <ashish.kalra@amd.com>]

Hello Boris,

On 6/19/2026 5:10 PM, Borislav Petkov wrote:
> On Fri, Jun 19, 2026 at 03:51:20PM -0500, Kalra, Ashish wrote:
>> 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.
> 
> What happened to using cpu_hotplug_disable_offlining() as I've been saying
> a bunch of times now?
> 

One thing about cpu_hotplug_disable_offlining() is that it is permanent and one-way (__ro_after_init). 

Once SNP host RMP/SNP is enabled at boot, offlining is disabled for the entire boot — no re-enable, even if
SNP is fully shut down later. In comparison, there is the possibility to re-enable CPU hotplugging during
SNP shutdown path by calling cpuhp_remove_state_nocalls().

It has to invoked at boot-time, so it's tied to "RMP/SNP host enabled at boot". So on a host with SNP/RMP enabled
but where SNP firmware is never initialized (KVM/SEV never used), it would still permanently disable CPU offlining — 
which is arguably wrong, since SNP isn't in use there. 

It is otherwise a clean interface, the offline path returns -EOPNOTSUPP, distinct from an -EBUSY return
via the cpuhp interface.

To summarize, using cpu_hotplug_disable_offlining() is simpler than the cpuhp interface, but the 
trade-offs are (a) coarser granularity (SNP enabled vs SNP initialized) and (b) no re-enable.

Thanks,
Ashish