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

[K Prateek Nayak]

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.

> 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 ;-)

-- 
Thanks and Regards,
Prateek