KVM: arm64: GICv4.1: Fix race with doorbell on VPE activation/deactivation

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166453 Upstream: Yes Test: non regression testing only

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.

Signed-off-by: Eric Auger eric.auger@redhat.com