Re: [PATCH v13 5/5] x86/sev: Re-enable RMP optimizations on SNP guest shutdown

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

On 9/2/2026 5:01 PM, sashiko-bot@kernel.org wrote:
> Pre-existing issues:
> - [High] Redundant and costly RMP optimization scan in hardirq context causing severe CPU stalls
> --
> 
> commit f95e55ff4f3219c5a1e0b2d2fc34fde539f227f7
> Author: Ashish Kalra <ashish.kalra@amd.com>
> x86/sev: Re-enable RMP optimizations on SNP guest shutdown
> 
> This commit introduces a mechanism to re-optimize memory on SNP guest
> shutdown using a delayed work queue to batch multiple terminations.
> 
>> diff --git a/arch/x86/virt/svm/sev.c b/arch/x86/virt/svm/sev.c
>> index a4c0fe49b9ec7..fb66a1aa6fc35 100644
>> --- a/arch/x86/virt/svm/sev.c
>> +++ b/arch/x86/virt/svm/sev.c
> [ ... ]
>> @@ -659,6 +659,33 @@ static void do_rmpopt_work(struct work_struct *work)
>>  	on_each_cpu_mask(cpu_primary_thread_mask, rmpopt_scan_range, NULL, true);
>>  }
>>  
>> +/*
>> + * Delay, in milliseconds, before the RMP re-optimization pass runs after an
>> + * SNP guest is torn down.
> [ ... ]
>> +void snp_rmpopt_all_physmem(void)
>> +{
>> +	if (!rmpopt_capable())
>> +		return;
>> +
>> +	guard(mutex)(&rmpopt_wq_mutex);
>> +
>> +	if (!rmpopt_wq)
>> +		return;
>> +
>> +	mod_delayed_work(rmpopt_wq, &rmpopt_delayed_work,
>> +			 msecs_to_jiffies(RMPOPT_WORK_TIMEOUT));
>> +}
> [Severity: High]
> This is a pre-existing issue, but queueing the do_rmpopt_work task upon guest 
> teardown exposes the host to severe CPU stalls.
> 
> Looking at do_rmpopt_work, it broadcasts an IPI to all primary threads:
> 
> arch/x86/virt/svm/sev.c:do_rmpopt_work() {
>     ...
>     migrate_disable();
>     rmpopt_scan_range(NULL);
>     migrate_enable();
> 
>     on_each_cpu_mask(cpu_primary_thread_mask, rmpopt_scan_range, NULL, true);
> }
> 
> The IPI handler rmpopt_scan_range executes the rmpopt hardware instruction 
> in hardirq context over up to 2TB of memory:
> 
> arch/x86/virt/svm/sev.c:rmpopt_scan_range() {
>     ...
>     for (pa = rmpopt_pa_start; pa < rmpopt_pa_end; pa += SZ_1G)
>         rmpopt(pa);
>     ...
> }
> 
> Since rmpopt is a very slow instruction, does iterating it over massive 
> memory ranges inside an IPI handler lead to soft lockups or host denial of 
> service, especially if frequent VM churn repeatedly tears down SNP guests 
> to trigger this scan?

Two things bound this:

1. Coalescing. snp_rmpopt_all_physmem() uses mod_delayed_work() with a 10 s
delay that is reset on every call, so a burst of guest teardowns does not
queue one scan per teardown — the pass runs once, 10 s after the last
teardown. Frequent VM churn is coalesced into a single pass, not amplified.

2. The IPI does not run an uncached scan. do_rmpopt_work() first runs
rmpopt_scan_range() once on the worker's own CPU under migrate_disable()
(interrupts on, preemptible), which does the expensive part and populates
the shared RMPOPT table — all primary threads share the same RMPOPT_BASE.
Only then does on_each_cpu_mask() fan out, and those RMPOPTs are cache hits
(reads of the already-computed result), so the IRQ-disabled window per CPU
is bounded by the cache-hit cost, not the scan cost — measured at ~320 ms
over the largest configuration tested, well under the soft-lockup/NMI
thresholds.

> 
> Additionally, because rmpopt_wq is created as WQ_UNBOUND, the worker 
> thread might run on an SMT sibling. If so, wouldn't the initial local scan 
> execute on a CPU where MSR_AMD64_RMPOPT_BASE was never configured, 
> potentially leading to undefined behavior or faults?

MSR_AMD64_RMPOPT_BASE has core scope, so programming it on each core's primary
thread configures it for both SMT threads of that core. A WQ_UNBOUND worker
that happens to run on a secondary thread therefore still executes RMPOPT
against a validly-configured RMPOPT_BASE (its core's), and since CPU hotplug
is disabled while SNP is active, every core stays configured. There is no CPU
on which RMPOPT_BASE is unconfigured, so no fault or undefined behaviour.

Thanks,
Ashish