Re: [PATCH v2 2/2] KVM: arm64: Resume a pKVM stage-2 teardown at the next mapping

[Vincent Donnefort <vdonnefort@google.com>]

On Wed, Nov 04, 2026 at 12:44:51PM +0000, Fuad Tabba wrote:
> pKVM keeps a VM's stage-2 mappings in an interval tree, and
> pkvm_pgtable_stage2_destroy_range() releases the ones in its range.
> stage2_destroy_range() still calls it for every block-sized chunk of the
> IPA space. As pKVM gives every VM the host's IPA limit, a teardown with
> LPA2 makes 2^27 calls with 16K pages (2^22 with 4K), however little the
> VM maps.
> 
> Return the address of the next mapping instead, or U64_MAX when none is
> left, so that the teardown skips the space between mappings. No mapping
> crosses a chunk boundary, as pKVM maps at most PMD_SIZE, so the next one
> starts at or above the end of the range. A VM without a handle doesn't
> have anything mapped, so return U64_MAX for it straight away.
> 
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
>  arch/arm64/kvm/pkvm.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index f21c3326dda68..77315c83c61b3 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -504,9 +504,10 @@ u64 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 addr + size;
> +		return U64_MAX;
>  
>  	if (pkvm_hyp_vm_is_created(kvm) && !kvm->arch.pkvm.is_dying) {
>  		WARN_ON(kvm_call_hyp_nvhe(__pkvm_start_teardown_vm, handle));
> @@ -518,7 +519,10 @@ u64 pkvm_pgtable_stage2_destroy_range(struct kvm_pgtable *pgt,
>  	else
>  		__pkvm_pgtable_stage2_unshare(pgt, addr, addr + size);
>  
> -	return addr + size;
> +	/* Mappings left by a failed release are still in the tree, so look past the range. */

Hum, not sure I understand that comment. Which release are we talking about? The
_reclaim or _unshare? If yes, we don't propagate the error and WARN if any of
them fails. So we don't expect any failure here and I'd say there's nothing
special to do?

Additionally, in any case, iter_first(addr + size) seems like the right thing to
do and is self-explanatory.

> +	mapping = pkvm_mapping_iter_first(&pgt->pkvm_mappings, addr + size, U64_MAX);
> +
> +	return mapping ? gfn_to_gpa(mapping->gfn) : U64_MAX;
>  }
>  
>  void pkvm_pgtable_stage2_destroy_pgd(struct kvm_pgtable *pgt)
> -- 
> 2.47.3
> 

Reviewed-by: Vincent Donnefort <vdonnefort@google.com>

-- 
Vincent