Re: [PATCH v11 5/6] x86/sev: Add interface to re-enable RMP optimizations.
From: Borislav Petkov
Date: Mon Aug 10 2026 - 13:32:15 EST
On Mon, Jul 27, 2026 at 07:05:54PM +0000, Ashish Kalra wrote:
> From: Ashish Kalra <ashish.kalra@xxxxxxx>
>
> RMPOPT table is a per-CPU table which indicates if 1GB regions of
> physical memory are entirely hypervisor-owned or not.
>
> When performing host memory accesses in hypervisor mode as well as
> non-SNP guest mode, the processor may consult the RMPOPT table to
> potentially skip an RMP access and improve performance.
>
> Normal guest events clear RMP optimizations: pages are converted from
s/clear/disable/
or "prevent RMP optimizations". "clear" sounds weird.
> shared to private as SNP guests are launched, and large pages are split
> and collapsed during guest operation -- both clear the RMPOPT
> optimizations for the affected 1GB regions.
> Conversely, guest pages are
Not "Conversely" but "When guests are torn down" or something to that effect.
> converted back to shared during SNP guest termination, so those regions
> may become eligible for RMPOPT optimization again.
>
> Without some intervention, all RMP optimizations would eventually be
> lost. Add an interface to re-optimize all of physical memory.
>
> The interface uses mod_delayed_work() instead of queue_delayed_work()
> so that the delay timer is reset on each call. This provides proper
> batching semantics: re-optimization runs 10 seconds after the *last*
> VM termination rather than after the first. mod_delayed_work() also
> re-queues work that is already in-flight, so a re-scan request
> during an active scan is not silently dropped.
And I keep wondering what are you even doing here until I saw the next patch.
Just merge the two into a single patch.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette