KVM: arm64: GICv4.1: Fix race with doorbell on VPE activation/deactivation
authorMarc Zyngier <maz@kernel.org>
Thu, 19 Jan 2023 11:07:59 +0000 (11:07 +0000)
committerMarc Zyngier <maz@kernel.org>
Sat, 21 Jan 2023 11:02:19 +0000 (11:02 +0000)
commitef3691683d7bfd0a2acf48812e4ffe894f10bfa8
tree8999d0666c58a1811c2283b2b46810cc1925366f
parentc3b37c2d77a2c735857c55492ee81e88e855497d
KVM: arm64: GICv4.1: Fix race with doorbell on VPE activation/deactivation

To save the vgic LPI pending state with GICv4.1, the VPEs must all be
unmapped from the ITSs so that the sGIC caches can be flushed.
The opposite is done once the state is saved.

This is all done by using the activate/deactivate irqdomain callbacks
directly from the vgic code. Crutially, this is done without holding
the irqdesc lock for the interrupts that represent the VPE. And these
callbacks are changing the state of the irqdesc. What could possibly
go wrong?

If a doorbell fires while we are messing with the irqdesc state,
it will acquire the lock and change the interrupt state concurrently.
Since we don't hole the lock, curruption occurs in on the interrupt
state. Oh well.

While acquiring the lock would fix this (and this was Shanker's
initial approach), this is still a layering violation we could do
without. A better approach is actually to free the VPE interrupt,
do what we have to do, and re-request it.

It is more work, but this usually happens only once in the lifetime
of the VM and we don't really care about this sort of overhead.

Fixes: f66b7b151e00 ("KVM: arm64: GICv4.1: Try to save VLPI state in save_pending_tables")
Reported-by: Shanker Donthineni <sdonthineni@nvidia.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230118022348.4137094-1-sdonthineni@nvidia.com
arch/arm64/kvm/vgic/vgic-v3.c
arch/arm64/kvm/vgic/vgic-v4.c
arch/arm64/kvm/vgic/vgic.h