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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

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?

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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788296083.git.ashish.kalra@amd.com?part=5