Re: [PATCH v10 2/6] x86/sev: Initialize RMPOPT configuration MSRs

On 7/23/2026 2:16 AM, K Prateek Nayak wrote:
> Hello Ashish,
> 
> On 7/23/2026 12:33 PM, Kalra, Ashish wrote:
>> Hello Prateek,
>>
>> On 7/23/2026 12:58 AM, K Prateek Nayak wrote:
>>> Hello Boris,
>>>
>>> On 7/23/2026 10:44 AM, Borislav Petkov wrote:
>>>> On Thu, Jul 23, 2026 at 10:23:56AM +0530, K Prateek Nayak wrote:
>>>>> The offline cores will remain offline since hotplug is disabled. RMPOPT
>>>>> is simply a performance optimization for RMP checks and leaving the
>>>>> offline cores (that will never exit idle) unoptimized should be
>>>>> acceptable.
>>>>
>>>> What happens if you boot with a subset of cores, the boot flow enables RMPOPT
>>>> and then you online the rest?
>>>
>>> RMPOPT happens at __sev_snp_init_locked() for all online cores. Until
>>> then, SnpEn is still 0 and we don't need RMPOPT because RMP checks
>>> haven't been enabled yet.
>>>
>>>>
>>>> Have we tried that?
>>>
>>> That said, Ashish, should snp_rmptable_init() do a
>>> snp_rmpopt_all_physmem() (or something equivalent) when it finds SNP_EN
>>> set in MSR_AMD64_SYSCFG after a kexec?
>>>
>>
>> It already happens, just later in the sequence. On kexec __sev_snp_init_locked() still runs: snp_prepare() returns early
>> (SnpEn set), SNP_INIT re-initializes the firmware context, and then snp_setup_rmpopt() is called.
> 
> But that only happens when the first SNP guest is created right? Until
> then RMP checks are enforced but no confidential guest is running and
> the CPUs are paying price for those checks.

Typically, on RMPOPT-capable platforms SnpEn isn't inherited across kexec. 

As i mentioned earlier (on v9 thread), kexec with SNP active currently requires
a full SNP shutdown before the kexec. SNP_SHUTDOWN_EX (and the IOMMU SNP shutdown it performs)
fail if there are any active SNP guests or assigned ASIDs, so a working kexec has to terminate
all SNP guests and run a full shutdown first (via systemctl kexec). 

Now, on any platform that supports the x86 SNP shutdown, that issues SNP_SHUTDOWN_EX with x86_snp_shutdown=1, 
the firmware clears SnpEn before the kexec. The kexec kernel boots with SnpEn clear, exactly like a normal boot. (The
only case SnpEn survives kexec is the legacy shutdown path, and those platforms don't support RMPOPT anyway.)

Thanks,
Ashish

> 
>> On the fresh kexec kernel, rmpopt_wq is NULL, so snp_setup_rmpopt() does the full setup — programs the per-CPU RMPOPT_BASE MSRs and
>> queues the initial all-physmem optimization pass. So RMPOPT is re-applied on kexec through the normal path.
>>
>> Doing it in snp_rmptable_init() would be too early: the per-CPU RMPOPT_BASE MSRs aren't programmed until
>> snp_setup_rmpopt(), so a pass there would have no base configured.
> 
> Ack! Which is why I mentioned something equivalent ;-)
>