]> www.infradead.org Git - users/jedix/linux-maple.git/commit
KVM: arm64: nv: Request vPE doorbell upon nested ERET to L2
authorOliver Upton <oliver.upton@linux.dev>
Tue, 25 Feb 2025 17:29:26 +0000 (17:29 +0000)
committerOliver Upton <oliver.upton@linux.dev>
Mon, 3 Mar 2025 22:57:10 +0000 (14:57 -0800)
commit93078ae63f20f09809c51e0505f8e8cc930d60ef
treeed90c6d17f0631630525e4ab484d4427436f21bd
parent69c9176c3862345850b7fecbe2546bfd051dc7da
KVM: arm64: nv: Request vPE doorbell upon nested ERET to L2

Running an L2 guest with GICv4 enabled goes absolutely nowhere, and gets
into a vicious cycle of nested ERET followed by nested exception entry
into the L1.

When KVM does a put on a runnable vCPU, it marks the vPE as nonresident
but does not request a doorbell IRQ. Behind the scenes in the ITS
driver's view of the vCPU, its_vpe::pending_last gets set to true to
indicate that context is still runnable.

This comes to a head when doing the nested ERET into L2. The vPE doesn't
get scheduled on the redistributor as it is exclusively part of the L1's
VGIC context. kvm_vgic_vcpu_pending_irq() returns true because the vPE
appears runnable, and KVM does a nested exception entry into the L1
before L2 ever gets off the ground.

This issue can be papered over by requesting a doorbell IRQ when
descheduling a vPE as part of a nested ERET. KVM needs this anyway to
kick the vCPU out of the L2 when an IRQ becomes pending for the L1.

Link: https://lore.kernel.org/r/20240823212703.3576061-4-oliver.upton@linux.dev
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20250225172930.1850838-13-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
arch/arm64/include/asm/kvm_host.h
arch/arm64/kvm/emulate-nested.c
arch/arm64/kvm/vgic/vgic-v4.c