On Thu, Jun 12, 2025 at 07:34:35AM -0700, Sean Christopherson wrote: > On Thu, Jun 12, 2025, Marc Zyngier wrote: > > On Wed, 11 Jun 2025 23:45:05 +0100, > > Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > > > WARN if unmapping a vLPI in kvm_vgic_v4_unset_forwarding() fails, as > > > failure means an IRTE has likely been left in a bad state, i.e. IRQs > > > won't go where they should. > > > > I have no idea what an IRTE is. > > Sorry, x86 IOMMU terminology (Interrupt Remapping Table Entry). I think the GIC > terminology would be ITS entry? Or maybe ITS mapping? We tend to just call it a 'vLPI mapping', which under the hood implies a couple other translations have been wired up as well (vPE + Device). > > But not having an VLPI mapping for an interrupt at the point where we're > > tearing down the forwarding is pretty benign. IRQs *still* go where they > > should, and we don't lose anything. The VM may not actually be getting torn down, though. The series of fixes [*] we took for 6.16 addressed games that VMMs might be playing on irqbypass for a live VM. [*] https://lore.kernel.org/kvmarm/20250523194722.4066715-1-oliver.upton@xxxxxxxxx/ > All of those failure scenario seem like warnable offences when KVM thinks it has > configured the IRQ to be forwarded to a vCPU. I tend to agree here, especially considering how horribly fragile GICv4 has been in some systems. I know of a couple implementations where ITS command failures and/or unmapped MSIs are fatal for the entire machine. Debugging them has been a genuine pain in the ass. WARN'ing when state tracking for vLPIs is out of whack would've made it a little easier. Thanks, Oliver
