[PATCH 0/3] KVM: arm64: Stop stage-2 teardown scaling with the IPA size

[Oliver Upton]

Hi Fuad,

On Tue, Nov 03, 2026 at 08:47:39AM +0000, Fuad Tabba wrote:
> Hi folks,
> 
> Two fixes for stage-2 teardown, which since 4ddfab5436b6 takes time
> proportional to the size of the IPA space rather than to what is mapped.
> 
> Under QEMU TCG ('-cpu max', 16K pages with LPA2), destroying even an
> empty VM takes about 7 seconds in pKVM. Without pKVM it takes about 19
> seconds if the VM requests a 52-bit IPA (crosvm requests the host's
> limit). I would expect it to scale the same way in hardware. I tested
> only under QEMU, since I don't have hardware with LPA2.
> 
> pKVM gives every VM the host's IPA limit. The first makes it release the
> VM's mappings from its tree instead of walking that space. My series
> honoring KVM_VM_TYPE_ARM_IPA_SIZE in pKVM [1] (respinning it soon)
> doesn't replace the fix, as crosvm requests the limit there too.
> 
> The second makes the non-pKVM teardown step over an empty entry larger
> than the largest block in one go, rather than start a new walk for each
> block-sized chunk of it. It depends on the first, as the lookup it adds
> reads fields that hold the mapping tree on a pKVM stage-2.
> 
> The third moves the pKVM/non-pKVM split in the teardown into
> kvm_vm_s2_ops, with no functional change. The first two apply back to
> 7.1, except that a backport of the second drops the flags argument 7.4
> added to kvm_pgtable_get_leaf().

I don't see why optimized destroy walks for CCA and pKVM is
fundamentally incompatible with driving them from a loop that
reschedules. Non-preemptible kernels are still very much a thing, I'd
rather not undo the fix we took for that exact use case.

So unless I'm missing something completely obvious, I'd rather that CCA
and pKVM do teardowns from that loop.

Thanks,
Oliver