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

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

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.

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.

Thanks,
Ashish