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

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

On 8/3/2026 4:02 PM, Borislav Petkov wrote:
> On August 3, 2026 7:37:59 PM UTC, "Kalra, Ashish" <ashish.kalra@amd.com> wrote:
>> RMPOPT_WORK_TIMEOUT is used by snp_rmpopt_all_physmem() (mod_delayed_work()), which is added in the next patch — I'll
>> move the define there so each patch is self-contained. 
> 
> Yes, very much so.
> 
>> It isn't periodic either: the handler doesn't re-arm itself. The work runs at setup and re-init with queue_delayed_work(), 
>> and then per SNP-guest teardown via mod_delayed_work() (batched by the timeout) once the later patches wire that up.
> 
> Then I am missing an important aspect here: RMPOPT optimizes RMP checks but then what's the point if you do this only on SNP guest teardown and I'm assuming at guest init too? 
> 
> What happens to long-running guests which never get restarted? 
> 
> This would lead to the system fragmenting ad absurdum and us never optimizing the RMP table practically.
> 
> But the guest could, in its lifetime, free up a contiguous 1G. When are we optimizing this one then?
> 
> Is that what the sentence about optimizing during 1GB page cleanup in your 0th message all about? 

The case where a guest frees a contiguous 1 GB mid-life is exactly the follow-on I mentioned in the cover letter —
yes, that's what the "optimizing during 1 GB page cleanup" sentence is about: once 1 GB hugetlb guest_memfd support lands,
RMPOPT re-optimization will hook that 1 GB cleanup path. I'll spell out these trigger points in the commit message.

Thanks,
Ashish

> 
> In any case, your commit message needs to talk about when those optimization runs are happening and why.
> 
> Thx.
>