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

On August 3, 2026 7:37:59 PM UTC, "Kalra, Ashish" <ashish=2Ekalra@amd=2Ecom=
> wrote:
>RMPOPT_WORK_TIMEOUT is used by snp_rmpopt_all_physmem() (mod_delayed_work=
()), which is added in the next patch =E2=80=94 I'll
>move the define there so each patch is self-contained=2E=20

Yes, very much so=2E

>It isn't periodic either: the handler doesn't re-arm itself=2E The work r=
uns at setup and re-init with queue_delayed_work(),=20
>and then per SNP-guest teardown via mod_delayed_work() (batched by the ti=
meout) once the later patches wire that up=2E

Then I am missing an important aspect here: RMPOPT optimizes RMP checks bu=
t then what's the point if you do this only on SNP guest teardown and I'm a=
ssuming at guest init too?=20

What happens to long-running guests which never get restarted?=20

This would lead to the system fragmenting ad absurdum and us never optimiz=
ing the RMP table practically=2E

But the guest could, in its lifetime, free up a contiguous 1G=2E When are =
we optimizing this one then?

Is that what the sentence about optimizing during 1GB page cleanup in your=
 0th message all about?=20

In any case, your commit message needs to talk about when those optimizati=
on runs are happening and why=2E

Thx=2E

--=20
Small device=2E Typos and formatting crap