Integrate NVIDIA Grace kernel fixes for vGIC

[Brad Figg]

[Impact]

    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.

    The upstream maintainer acknowledged the bug, fixed the issue. and it will be available in v6.2.

[Fixes]
    - single patch to address the race condition on VPE activation/deactivation

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-nvidia-5.19 - 5.19.0-1007.7

---------------
linux-nvidia-5.19 (5.19.0-1007.7) jammy; urgency=medium

  * jammy/linux-nvidia-5.19: 5.19.0-1007.7 -proposed tracker (LP: #2003754)

  * Integrate NVIDIA Grace kernel fixes for vGIC (LP: #2003640)
    - SAUCE: KVM: arm64: GICv4.1: Fix race with doorbell on VPE
      activation/deactivation

 -- Ian May <email address hidden> Tue, 24 Jan 2023 16:28:34 -0600