Re: [PATCH 2/2] KVM: arm64: selftests: Add a nested S2 MMU realloc test

[Marc Zyngier <maz@kernel.org>]

On Mon, 03 Aug 2026 23:44:05 +0100,
Karl Mehltretter <kmehltretter@gmail.com> wrote:
> 
> Add a regression test for a stale vcpu->arch.hw_mmu reference when
> initialising a vCPU grows the nested S2 MMU table.
> 
> The test drives vCPU0 into L2 through a minimal L1 stage-2 identity map,
> pins it to a second pCPU where it spins in L2, and then initialises
> vCPU1.  That initialisation grows the nested MMU table while vCPU0 still
> holds one of its entries; keeping vCPU0 on a pCPU of its own means the
> reference stays live without relying on hw_mmu being retained across a
> schedule-out.  vCPU0 is then released and has to run to completion.
> 
> Creating vCPU1 up front is what allows the in-kernel VGIC to be used:
> kvm_arch_vcpu_precreate() refuses KVM_CREATE_VCPU once the VGIC has been
> initialised, which the test does before its first KVM_RUN.  Creation on
> its own increments online_vcpus, so deferring vCPU1's KVM_ARM_VCPU_INIT
> until vCPU0 is in L2 still grows the table.
> 
> With KASAN enabled, an unfixed kernel reports a slab-use-after-free in
> kvm_handle_guest_abort(); with the fix it completes cleanly.

The problem is that we can't mandate selftests to rely on KASAN on the
host. Selftests are there to verify that we match the architecture
requirements.

If anything, this is a nice hack to demonstrate the problem (and yes,
it fires here).

> 
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> 
> The test requires nested virtualization and two pCPUs.  Under QEMU TCG
> it takes ~233s, exceeding the 120s timeout in
> tools/testing/selftests/kvm/settings; psci_test takes ~167s in the same
> boot, so emulating the second vCPU is the dominant cost.

# time /host/home/maz/nested_mmu_realloc_test 
Random seed: 0x6b8b4567
Running control thread on pCPU 0, vCPU thread on pCPU 1
vCPU0 is running in L2; initializing vCPU1 to grow the table
vCPU1 initialized; releasing vCPU0
vCPU0 resumed after nested MMU resize

real	0m0.161s
user	0m0.007s
sys	0m0.109s

This is with KVM running as an L1 already...

	M.

-- 
Without deviation from the norm, progress is not possible.