irqchip/gic-v4: Fix VMAPP/VMOVP races

In [email protected], Nianyao reports a number of possible races that can trigger on GICv4 implementations using the ITSList feature.

These races involve concurrent VMOVP and VMAPP, the former happening on vcpu load, while the latter is triggered on the first device being MAPTI'd on a given ITS for this particular guest.

The main issue is that we want to establish the affinity at VMAPP time, while vcpu_load wants to set the affinity where the vcpu actually runs. Lock ordering constraints mean that we can't lock the VPE on VMAPP, so things are modified without any lock. What could possibly go wrong?

THe fix is a bit involved, and relies on 3 things:

- Making sure that the initial affinity of a VPE is fixed at activate time, which is done early in the life of the vcpup, before it can run.

- Add a per-VM lock that can be taken instead of the global vmovp_lock, paving the way for a more manageable lock order.

- Take the per-VPE lock whenever modifying the VPE affinity, as expected everywhere else in the code.

With that, VMAPP and VMOVP can now run concurrently and still lead to sensible results.

Marc Zyngier (3):
irqchip/gic-v4: Always configure affinity on VPE activation irqchip/gic-v4: Substitute vmovp_lock for a per-VM lock irqchip/gic-v4: Make sure a VPE is locked when VMAPP is issued

 drivers/irqchip/irq-gic-v3-its.c   | 48 ++++++++++++++----------------
 include/linux/irqchip/arm-gic-v4.h |  8 +++++
 2 files changed, 30 insertions(+), 26 deletions(-)

2.39.2