Re: [PATCH v15 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:
- [High] kvm: system-wide synchronous IPI broadcast on every SNP guest teardown defeats batching
--

commit 23bdc9ba80b8a413abe236834cbaf2ae517ee599
Author: Ashish Kalra <ashish.kalra@amd.com>

x86/sev: Re-enable RMP optimizations on SNP guest shutdown

The RMPOPT table indicates whether 1GB regions of physical memory are
entirely hypervisor-owned. When SNP guests are torn down, this patch
re-optimizes all of physical memory by calling snp_enable_rmpopt(). This
process is intended to be batched using a delayed work queue to avoid
overhead during multiple guest terminations.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 0a887f8e05d3a..e05adec44d0aa 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -3032,6 +3032,8 @@ void sev_vm_destroy(struct kvm *kvm)
>  		 */
>  		if (snp_decommission_context(kvm))
>  			return;
> +
> +		snp_enable_rmpopt();

[Severity: High]
The commit message mentions that using mod_delayed_work() batches multiple
guest terminations into a single pass.

However, doesn't calling snp_enable_rmpopt() here on every guest teardown
trigger a synchronous system-wide IPI broadcast each time?

arch/x86/virt/svm/sev.c:snp_enable_rmpopt() {
    ...
    on_each_cpu_mask(cpu_primary_thread_mask, rmpopt_program_base, NULL, 1);

    mod_delayed_work(rmpopt_wq, &rmpopt_delayed_work, ...);
    ...
}

Could this unbatched IPI broadcast cause severe performance degradation and
latency spikes across the system when multiple guests are torn down rapidly,
defeating the batching intent?

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