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

[Borislav Petkov]

On August 3, 2026 7:37:59 PM UTC, "Kalra, Ashish" <ashish.kalra@xxxxxxx> 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? 

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

Thx.

-- 
Small device. Typos and formatting crap