From: Vincent Donnefort <vdonnefort@google.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Raghavendra Rao Ananta <rananta@google.com>,
Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH 1/3] KVM: arm64: Don't walk the whole IPA space when destroying a pKVM stage-2
Date: Tue, 3 Nov 2026 16:37:54 +0000 [thread overview]
Message-ID: <auoN4h8iloqPuepc@google.com> (raw)
In-Reply-To: <20261103084742.1302597-2-fuad.tabba@linux.dev>
On Tue, Nov 03, 2026 at 08:47:40AM +0000, Fuad Tabba wrote:
> Since commit 4ddfab5436b6 ("KVM: arm64: Reschedule as needed when
> destroying the stage-2 page-tables"), kvm_stage2_destroy() steps through
> the IPA space in block-sized chunks, and with pKVM each chunk is a
> lookup in the VM's mapping tree. However, pKVM gives every VM the host's
> IPA limit, so with LPA2 a teardown makes 2^27 lookups with 16K pages
> (2^22 with 4K), nearly all of them for empty space.
>
> Walk the mapping tree once instead, and reschedule after passing each
> mapping to the reclaim or unshare helper. The unshare helper can't
> reschedule itself, as the map and unmap paths call it under the
> mmu_lock. A failed unshare now leaves only its own mapping behind, not
> the rest of its chunk.
>
> Fixes: 4ddfab5436b69 ("KVM: arm64: Reschedule as needed when destroying the stage-2 page-tables")
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
> arch/arm64/kvm/mmu.c | 7 ++++++-
> arch/arm64/kvm/pkvm.c | 17 +++++++++++++----
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1db10d8d6db73..42977cf8a7f5d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1022,7 +1022,12 @@ static void kvm_stage2_destroy(struct kvm_pgtable *pgt)
> {
> unsigned int ia_bits = VTCR_EL2_IPA(pgt->mmu->vtcr);
>
> - stage2_destroy_range(pgt, 0, BIT(ia_bits));
> + /* pKVM walks its mapping tree, not the IPA space, and reschedules per mapping */
> + if (is_protected_kvm_enabled())
> + pkvm_pgtable_stage2_destroy_range(pgt, 0, BIT(ia_bits));
> + else
> + stage2_destroy_range(pgt, 0, BIT(ia_bits));
> +
> KVM_PGT_FN(kvm_pgtable_stage2_destroy_pgd)(pgt);
> }
>
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 016997288fd23..992ed3ca6bdd9 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -504,6 +504,7 @@ void pkvm_pgtable_stage2_destroy_range(struct kvm_pgtable *pgt,
> {
> struct kvm *kvm = kvm_s2_mmu_to_kvm(pgt->mmu);
> pkvm_handle_t handle = kvm->arch.pkvm.handle;
> + struct pkvm_mapping *mapping;
>
> if (!handle)
> return;
> @@ -513,10 +514,18 @@ void pkvm_pgtable_stage2_destroy_range(struct kvm_pgtable *pgt,
> kvm->arch.pkvm.is_dying = true;
> }
>
> - if (kvm_vm_is_protected(kvm))
> - __pkvm_pgtable_stage2_reclaim(pgt, addr, addr + size);
> - else
> - __pkvm_pgtable_stage2_unshare(pgt, addr, addr + size);
> + /* Called once for the whole IPA space, so reschedule between mappings */
> + for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> + u64 start = __pkvm_mapping_start(mapping);
> + u64 end = __pkvm_mapping_end(mapping) + 1;
> +
> + if (kvm_vm_is_protected(kvm))
> + __pkvm_pgtable_stage2_reclaim(pgt, start, end);
> + else
> + __pkvm_pgtable_stage2_unshare(pgt, start, end);
> +
> + cond_resched();
> + }
> }
Just thought that it is a bit weird that pkvm_pgtable_stage2_destroy_range()
does cond_resched() while kvm_pgtable_stage2_destroy_range() does not.
How about instead kvm_stage2_destroy() refines start/end with some accessors
calling in pkvm.c pkvm_mapping_iter_first() / pkvm_mapping_iter_last()?
>
> void pkvm_pgtable_stage2_destroy_pgd(struct kvm_pgtable *pgt)
> --
> 2.47.3
>
>
--
Vincent
next prev parent reply other threads:[~2026-11-03 16:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 8:47 [PATCH 0/3] KVM: arm64: Stop stage-2 teardown scaling with the IPA size Fuad Tabba
2026-11-03 8:47 ` [PATCH 1/3] KVM: arm64: Don't walk the whole IPA space when destroying a pKVM stage-2 Fuad Tabba
2026-11-03 14:52 ` Vincent Donnefort
2026-11-03 16:15 ` Fuad Tabba
2026-11-03 16:26 ` Marc Zyngier
2026-11-03 16:27 ` Fuad Tabba
2026-11-03 16:37 ` Vincent Donnefort [this message]
2026-11-03 16:47 ` Oliver Upton
2026-11-03 16:48 ` Oliver Upton
2026-11-03 8:47 ` [PATCH 2/3] KVM: arm64: Skip empty IPA ranges when destroying stage-2 page-tables Fuad Tabba
2026-11-03 10:27 ` Suzuki K Poulose
2026-11-03 16:19 ` Fuad Tabba
2026-11-03 16:55 ` Oliver Upton
2026-11-03 8:47 ` [PATCH 3/3] KVM: arm64: Move stage-2 teardown into kvm_vm_s2_ops Fuad Tabba
2026-11-03 9:37 ` Suzuki K Poulose
2026-11-03 10:33 ` Suzuki K Poulose
2026-11-03 16:22 ` Fuad Tabba
2026-11-03 17:03 ` [PATCH 0/3] KVM: arm64: Stop stage-2 teardown scaling with the IPA size Oliver Upton
2026-11-03 19:08 ` 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=auoN4h8iloqPuepc@google.com \
--to=vdonnefort@google.com \
--cc=catalin.marinas@arm.com \
--cc=fuad.tabba@linux.dev \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=rananta@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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 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.