From: "Kalra, Ashish" <ashish.kalra@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, seanjc@google.com,
peterz@infradead.org, thomas.lendacky@amd.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
ardb@kernel.org, pbonzini@redhat.com, aik@amd.com,
Michael.Roth@amd.com, KPrateek.Nayak@amd.com,
Tycho.Andersen@amd.com, Nathan.Fontenot@amd.com,
ackerleytng@google.com, jackyli@google.com, pgonda@google.com,
rientjes@google.com, jacobhxu@google.com, xin@zytor.com,
pawan.kumar.gupta@linux.intel.com, babu.moger@amd.com,
dyoung@redhat.com, nikunj@amd.com, john.allen@amd.com,
darwi@linutronix.de, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, kvm@vger.kernel.org,
linux-coco@lists.linux.dev
Subject: Re: [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously
Date: Wed, 5 Aug 2026 16:04:15 -0500 [thread overview]
Message-ID: <9a54ea1c-73bd-469b-9f87-906fa269029c@amd.com> (raw)
In-Reply-To: <20260805192837.GAanOO5SU78CzNgblB@fat_crate.local>
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
next prev parent reply other threads:[~2026-08-05 21:04 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 19:00 [PATCH v11 0/6] Add RMPOPT support Ashish Kalra
2026-07-27 19:01 ` [PATCH v11 1/6] x86/cpufeatures: Add X86_FEATURE_RMPOPT feature flag Ashish Kalra
2026-07-27 19:01 ` Ashish Kalra
2026-07-27 19:03 ` Ashish Kalra
2026-07-27 19:04 ` [PATCH v11 2/6] x86/sev: Disable CPU hotplug while SNP is active Ashish Kalra
2026-07-27 19:37 ` sashiko-bot
2026-07-27 20:44 ` Kalra, Ashish
2026-07-29 2:15 ` Borislav Petkov
2026-07-29 17:51 ` Kalra, Ashish
2026-07-31 19:35 ` Tom Lendacky
2026-07-31 20:27 ` Kalra, Ashish
2026-07-27 19:04 ` [PATCH v11 3/6] x86/sev: Initialize RMPOPT configuration MSRs Ashish Kalra
2026-07-27 19:22 ` sashiko-bot
2026-07-27 21:02 ` Kalra, Ashish
2026-07-30 2:07 ` Borislav Petkov
2026-07-30 2:55 ` K Prateek Nayak
2026-07-30 3:39 ` Borislav Petkov
2026-07-30 19:52 ` Kalra, Ashish
2026-07-30 20:00 ` Kalra, Ashish
2026-07-31 0:12 ` Borislav Petkov
2026-07-31 19:43 ` Tom Lendacky
2026-07-27 19:05 ` [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously Ashish Kalra
2026-07-27 19:22 ` sashiko-bot
2026-07-27 20:49 ` Kalra, Ashish
2026-07-31 5:44 ` Borislav Petkov
2026-07-31 12:37 ` Kalra, Ashish
2026-08-03 18:56 ` Kalra, Ashish
2026-08-03 19:24 ` Borislav Petkov
2026-08-03 19:37 ` Kalra, Ashish
2026-08-03 21:02 ` Borislav Petkov
2026-08-03 21:23 ` Kalra, Ashish
2026-08-03 21:38 ` Borislav Petkov
2026-08-03 22:22 ` Kalra, Ashish
2026-08-05 0:49 ` Borislav Petkov
2026-08-05 2:38 ` Kalra, Ashish
2026-08-05 19:28 ` Borislav Petkov
2026-08-05 21:04 ` Kalra, Ashish [this message]
2026-08-05 15:12 ` Dave Hansen
2026-08-05 19:33 ` Borislav Petkov
2026-08-03 21:10 ` Borislav Petkov
2026-07-31 20:14 ` Tom Lendacky
2026-07-27 19:05 ` [PATCH v11 5/6] x86/sev: Add interface to re-enable RMP optimizations Ashish Kalra
2026-07-27 19:06 ` [PATCH v11 6/6] KVM: SEV: Perform RMP optimizations on SNP guest shutdown Ashish Kalra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9a54ea1c-73bd-469b-9f87-906fa269029c@amd.com \
--to=ashish.kalra@amd.com \
--cc=KPrateek.Nayak@amd.com \
--cc=Michael.Roth@amd.com \
--cc=Nathan.Fontenot@amd.com \
--cc=Tycho.Andersen@amd.com \
--cc=ackerleytng@google.com \
--cc=aik@amd.com \
--cc=ardb@kernel.org \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=darwi@linutronix.de \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dyoung@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jackyli@google.com \
--cc=jacobhxu@google.com \
--cc=john.allen@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pgonda@google.com \
--cc=rientjes@google.com \
--cc=seanjc@google.com \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=xin@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.