irqchip/gic-v4: Wait for GICR_VPENDBASER.Dirty to clear before descheduling
authorMarc Zyngier <maz@kernel.org>
Thu, 17 Mar 2022 09:49:02 +0000 (09:49 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 13 Apr 2022 18:03:26 +0000 (20:03 +0200)
commit1b95786fcbbeaa06b807ccea9f599368bd61d88e
tree17961c67f3ec8f543e77e4abedb7693cf37853e9
parent5b4b6fe4ac00dee8f885863e7e353945fa5b0a33
irqchip/gic-v4: Wait for GICR_VPENDBASER.Dirty to clear before descheduling

commit af27e41612ec7e5b4783f589b753a7c31a37aac8 upstream.

The way KVM drives GICv4.{0,1} is as follows:
- vcpu_load() makes the VPE resident, instructing the RD to start
  scanning for interrupts
- just before entering the guest, we check that the RD has finished
  scanning and that we can start running the vcpu
- on preemption, we deschedule the VPE by making it invalid on
  the RD

However, we are preemptible between the first two steps. If it so
happens *and* that the RD was still scanning, we nonetheless write
to the GICR_VPENDBASER register while Dirty is set, and bad things
happen (we're in UNPRED land).

This affects both the 4.0 and 4.1 implementations.

Make sure Dirty is cleared before performing the deschedule,
meaning that its_clear_vpend_valid() becomes a sort of full VPE
residency barrier.

Reported-by: Jingyi Wang <wangjingyi11@huawei.com>
Tested-by: Nianyao Tang <tangnianyao@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Fixes: 57e3cebd022f ("KVM: arm64: Delay the polling of the GICR_VPENDBASER.Dirty bit")
Link: https://lore.kernel.org/r/4aae10ba-b39a-5f84-754b-69c2eb0a2c03@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/irqchip/irq-gic-v3-its.c