aboutsummaryrefslogtreecommitdiffstats
path: root/net/unix/unix_bpf.c
diff options
context:
space:
mode:
authorOliver Upton <[email protected]>2025-02-25 17:29:26 +0000
committerOliver Upton <[email protected]>2025-03-03 22:57:10 +0000
commit93078ae63f20f09809c51e0505f8e8cc930d60ef (patch)
treeed90c6d17f0631630525e4ab484d4427436f21bd /net/unix/unix_bpf.c
parentKVM: arm64: nv: Respect virtual HCR_EL2.TWx setting (diff)
downloadkernel-93078ae63f20f09809c51e0505f8e8cc930d60ef.tar.gz
kernel-93078ae63f20f09809c51e0505f8e8cc930d60ef.zip
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/[email protected] Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
Diffstat (limited to 'net/unix/unix_bpf.c')
0 files changed, 0 insertions, 0 deletions