Re: [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously

On 8/5/2026 2:28 PM, Borislav Petkov wrote:
> On Tue, Aug 04, 2026 at 09:38:05PM -0500, Kalra, Ashish wrote:
>> - Under churn (many SNP guests terminating and respawning), an hourly scan
>> is too coarse — freed regions would sit un-optimized for up to an hour. The
>> teardown trigger re-optimizes right after each burst of terminations
>> (batched by the timeout), so it's more responsive than a periodic scan
>> exactly when there's the most optimization work to do.
> 
> Yes.
> 
>> - When no SNP guests run, a periodic scan achieves nothing: the initial pass
>> already optimized all of memory and nothing has changed, so it just re-scans
>> physmem for zero benefit.
> 
> Well, no. You won't even run that when there are no SNP guests present.
> 
>> So the event-driven approach self-scales with real work — it runs as often
>> as memory is actually freed and not at all when the system is idle — whereas
>> a fixed timer is both too slow under load and pure overhead when idle. The
>> mid-life contiguous-1 GB case is then caught precisely by the 1 GB-hugetlb
>> page-cleanup hook when that lands, rather than by a coarse sweep.
> 
> I wanted to have this in case pages do get freed up from time to time and you
> get some sort of a fragmentation. But I'm being told that we don't support
> balooning yet, neither memory hotplug and when the pages get freed, they
> remain guest-owned. So yes, the points in time where those page become
> HV-owned and potentially freed, then we should optimize.
> 
> Please hold down that in the commit message so that it is clear for future
> readers why we did it this way.
> 

Will do — I have updated the patch 6 commit message to spell out why re-optimization is tied to guest teardown: SNP guests don't
support ballooning or memory hotplug yet, so pages freed during a guest's lifetime stay guest-owned, and teardown is the only
point where memory returns to hypervisor ownership and becomes eligible for re-optimization. That will be in the next revision.

Thanks,
Ashish