From: Vincent Donnefort <vdonnefort@google.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: maz@kernel.org, oupton@kernel.org, kvmarm@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com,
seiden@linux.ibm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
kernel-team@android.com, qperret@google.com
Subject: Re: [PATCH v4 10/17] KVM: arm64: Add a shrinker for pKVM
Date: Mon, 24 Aug 2026 17:38:37 +0100 [thread overview]
Message-ID: <aoxzjag7xr_emuvX@google.com> (raw)
In-Reply-To: <CA+EHjTxU2GCpSR587oR_EaMOvXfu+teCnfC2KCg=vpOtf4sgRA@mail.gmail.com>
On Tue, Aug 18, 2026 at 04:28:38PM +0100, Fuad Tabba wrote:
> Hi Vincent,
>
> On Fri, 31 Jul 2026 at 15:36, 'Vincent Donnefort' via kernel-team
> <kernel-team@android.com> wrote:
> >
> > Integrate the pKVM memory reclaim interface with the host's memory
> > management subsystem.
> >
> > This allows the host to automatically recover unused memory fom the
> > hypervisor's heap allocator when the host is under memory pressure.
> >
> > Tested-by: Fuad Tabba <fuad.tabba@linux.dev>
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > index d28422f5c3d6..bfbb1266491d 100644
> > --- a/arch/arm64/kvm/pkvm.c
> > +++ b/arch/arm64/kvm/pkvm.c
> > @@ -115,7 +115,7 @@ static int pkvm_hyp_topup(enum pkvm_topup_id id, unsigned long nr_pages)
> > return ret;
> > }
> >
> > -static __maybe_unused unsigned long pkvm_hyp_reclaim(enum pkvm_topup_id id, unsigned long target)
> > +static unsigned long pkvm_hyp_reclaim(enum pkvm_topup_id id, unsigned long target)
>
> This is the first caller of these, so it is where reclaim starts
> running against a concurrent top-up.
>
> Nothing marks the pages a top-up just put in allocator->mc as spoken
> for, and hyp_allocator_reclaim() ends with an unbounded drain of it,
> so a shrink with target 1 hands back the lot. Land that between a
> top-up and the retry it was for, and the retry asks again, and
> pkvm_call_hyp_req() goes round.
Sorry, I am not sure I follow here.
IIRC, the shrinker will only reclaim half of what is available. So the pressure
should be proportional to what is available and limit races with topup!
However now looking at it. I wonder if I don't want to ratelimit here the number
of pages reclaimed in one go to limit the time spent at EL2. Especially we do
all that with the allocator lock taken...
>
> Both are driven by memory pressure, so they are busiest together.
> Worth holding back what a pending request asked for?
>
> > {
> > struct kvm_hyp_memcache mc;
> > struct arm_smccc_res res;
> > @@ -133,7 +133,7 @@ static __maybe_unused unsigned long pkvm_hyp_reclaim(enum pkvm_topup_id id, unsi
> > return reclaimed;
> > }
> >
> > -static __maybe_unused unsigned long pkvm_hyp_reclaimable(enum pkvm_topup_id id)
> > +static unsigned long pkvm_hyp_reclaimable(enum pkvm_topup_id id)
> > {
> > return kvm_call_hyp_nvhe(__pkvm_hyp_reclaimable, id);
> > }
> > @@ -342,8 +342,19 @@ void __init pkvm_selftests(void)
> > #endif
> > }
> >
> > +static unsigned long pkvm_shrinker_count(struct shrinker *shrink, struct shrink_control *sc)
> > +{
> > + return pkvm_hyp_reclaimable(PKVM_TOPUP_HYP_ALLOC) ?: SHRINK_EMPTY;
> > +}
> > +
> > +static unsigned long pkvm_shrinker_scan(struct shrinker *shrink, struct shrink_control *sc)
> > +{
> > + return pkvm_hyp_reclaim(PKVM_TOPUP_HYP_ALLOC, sc->nr_to_scan);
> > +}
>
> Returning 0 rather than SHRINK_STOP when reclaim comes back empty
> leaves do_shrink_slab() calling this until total_scan runs out, and
> each call is an HVC. count_objects() covers the case where there is
> nothing at all, but not the one where it goes stale between the two
> calls.
>
> Cheers,
> /fuad
Ha right, that SHRINK_STOP seems indeed to be the convention for other users.
--
Vincent
>
> > +
> > static int __init finalize_pkvm(void)
> > {
> > + struct shrinker *pkvm_shrinker;
> > int ret;
> >
> > if (!is_protected_kvm_enabled() || !is_kvm_arm_initialised())
> > @@ -359,10 +370,21 @@ static int __init finalize_pkvm(void)
> > kmemleak_free_part_phys(hyp_mem_base, hyp_mem_size);
> >
> > ret = pkvm_drop_host_privileges();
> > - if (ret)
> > + if (ret) {
> > pr_err("Failed to finalize Hyp protection: %d\n", ret);
> > + return ret;
> > + }
> >
> > - return ret;
> > + pkvm_shrinker = shrinker_alloc(0, "pkvm");
> > + if (pkvm_shrinker) {
> > + pkvm_shrinker->count_objects = pkvm_shrinker_count;
> > + pkvm_shrinker->scan_objects = pkvm_shrinker_scan;
> > + shrinker_register(pkvm_shrinker);
> > + } else {
> > + kvm_err("Failed to register shrinker for pKVM\n");
> > + }
> > +
> > + return 0;
> > }
> > device_initcall_sync(finalize_pkvm);
> >
> > --
> > 2.55.0.508.g3f0d502094-goog
> >
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
> >
>
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@android.com.
>
next prev parent reply other threads:[~2026-08-24 16:38 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 14:35 [PATCH v4 00/17] KVM: arm64: Introduce pKVM hypervisor heap allocator Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 01/17] KVM: arm64: Add pkvm_private_va_range_pa Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 02/17] KVM: arm64: Add pkvm_remove_mappings Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 03/17] KVM: arm64: Add pkvm_map_private_va_range Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 04/17] KVM: arm64: Add a heap allocator for the pKVM hyp Vincent Donnefort
2026-08-18 14:22 ` Fuad Tabba
2026-08-24 15:19 ` Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 05/17] KVM: arm64: Allow kvm_hyp_memcache usage outside of stage-2 Vincent Donnefort
2026-07-31 14:51 ` sashiko-bot
2026-07-31 14:35 ` [PATCH v4 06/17] KVM: arm64: Add pkvm_hyp_req infrastructure Vincent Donnefort
2026-07-31 14:45 ` sashiko-bot
2026-08-18 15:33 ` Fuad Tabba
2026-08-25 7:41 ` Aneesh Kumar K.V
2026-08-25 8:10 ` Vincent Donnefort
2026-08-25 8:51 ` Fuad Tabba
2026-08-25 13:28 ` Aneesh Kumar K.V
2026-07-31 14:35 ` [PATCH v4 07/17] KVM: arm64: Add PKVM_HYP_REQ_HYP_ALLOC request Vincent Donnefort
2026-07-31 14:52 ` sashiko-bot
2026-08-18 15:11 ` Fuad Tabba
2026-08-18 15:12 ` Fuad Tabba
2026-07-31 14:35 ` [PATCH v4 08/17] KVM: arm64: Add reclaim interface for the pKVM heap alloc Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 09/17] KVM: arm64: Add selftests for the pKVM heap allocator Vincent Donnefort
2026-07-31 15:03 ` sashiko-bot
2026-08-18 15:43 ` Fuad Tabba
2026-08-24 16:23 ` Vincent Donnefort
2026-08-24 18:15 ` Fuad Tabba
2026-07-31 14:35 ` [PATCH v4 10/17] KVM: arm64: Add a shrinker for pKVM Vincent Donnefort
2026-08-18 15:28 ` Fuad Tabba
2026-08-24 16:38 ` Vincent Donnefort [this message]
2026-08-24 18:10 ` Fuad Tabba
2026-08-25 7:22 ` Vincent Donnefort
2026-08-25 7:40 ` Fuad Tabba
2026-08-25 8:20 ` Vincent Donnefort
2026-08-25 8:38 ` Fuad Tabba
2026-07-31 14:35 ` [PATCH v4 11/17] KVM: arm64: Filter out non-kernel addresses in kern_hyp_va Vincent Donnefort
2026-08-18 14:45 ` Fuad Tabba
2026-08-25 9:34 ` Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 12/17] KVM: arm64: Move hyp_vm refcount into the structure Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 13/17] KVM: arm64: Alloc pkvm_hyp_vm using pKVM heap allocator Vincent Donnefort
2026-07-31 15:06 ` sashiko-bot
2026-08-17 13:38 ` Fuad Tabba
2026-07-31 14:35 ` [PATCH v4 14/17] KVM: arm64: Alloc pkvm_hyp_vcpu " Vincent Donnefort
2026-07-31 15:04 ` sashiko-bot
2026-08-17 13:39 ` Fuad Tabba
2026-07-31 14:35 ` [PATCH v4 15/17] KVM: arm64: Reject hyp trace descriptors with fewer CPUs than hyp_nr_cpus Vincent Donnefort
2026-07-31 14:35 ` [PATCH v4 16/17] KVM: arm64: Reject hyp trace descriptors with fewer than 3 pages Vincent Donnefort
2026-08-17 14:00 ` Fuad Tabba
2026-07-31 14:35 ` [PATCH v4 17/17] KVM: arm64: Alloc simple_buffer_page using pKVM hyp allocator Vincent Donnefort
2026-08-17 14:16 ` Fuad Tabba
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=aoxzjag7xr_emuvX@google.com \
--to=vdonnefort@google.com \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox