Re: [PATCH v10 3/6] x86/sev: Disable CPU hotplug while SNP is active

[Kalra, Ashish]

On 7/23/2026 3:39 PM, Kalra, Ashish wrote:
> 
> On 7/23/2026 3:00 PM, Borislav Petkov wrote:
>> On Thu, Jul 23, 2026 at 02:44:47PM -0500, Kalra, Ashish wrote:
>>> Actually, i will have to remove cpus_read_lock()/unlock() across the whole
>>> patch series and also in the original code.
>>
>> You need to do that in the same patch which adds the hotplug disable so that
>> there's no hole in hotplug handling when bisecting.
>>
>> Make sure to explain why you're doing that in the commit message.
>>
>> Thx.
>>
> 
> This is the list of the consolidated changes:
> 
> Patch 2:  "Initialize RMPOPT configuration MSRs":
>   - Renamed rmpopt_cleanup() to snp_cleanup_rmpopt() to match snp_setup_rmpopt().
>   - Simplified the 2 TB RMPOPT_BASE comment.
>   - Replaced the misleading primary-thread comment with "…only one thread per core needs to set up the RMPOPT_BASE MSR. All
>   primary threads are online, otherwise SNP would not have been enabled."
> 
>  
> Patch 3:  "Disable CPU hotplug while SNP is active":
>   - Used your commit message.
>   - Since CPU hotplug is disabled while SNP is active, the online mask is stable, so I dropped the redundant
>   cpus_read_lock()/cpus_read_unlock() in snp_prepare() and the cpus_read_lock() in snp_setup_rmpopt()/snp_cleanup_rmpopt() —
>   all in this same patch so there's no hole in hotplug handling when bisecting, and explained why in the commit message.
>   - Dropped the superfluous "SnpEn was never set" comment and rewrote the snp_shutdown() re-enable comment.
> 
> The RMPOPT scan in rmpopt_work_handler() (added in 4/6) is likewise lock-free — it runs only while SNP is active, i.e.
> after the hotplug-disable patch, so it never needed cpus_read_lock() in the first place.
> 

Actually for v11, I am reordering the patches so "Disable CPU hotplug" comes before "Initialize RMPOPT configuration MSRs." 

snp_prepare()'s cpus_read_lock() is then dropped in the hotplug-disable patch itself (bisect stays clean, explained in the commit
message), and snp_setup_rmpopt()/snp_cleanup_rmpopt() — introduced afterwards — never take it in the first place, same as
rmpopt_work_handler(). So the removal is implied by ordering rather than an add-then-remove.

Also folded in: renamed rmpopt_cleanup() to snp_cleanup_rmpopt(), simplified the RMPOPT_BASE comment and the primary-thread
comment and used your reworded hotplug commit message.

Thanks,  
Ashish