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

[Kalra, Ashish]

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.

Thanks,
Ashish