Re: [PATCH v3 02/62] KVM: arm64: WARN if unmapping vLPI fails
From: Sean Christopherson <seanjc@google.com>
Date: 2025-06-20 19:04:21
Also in:
kvm, kvmarm, linux-iommu, lkml
On Fri, Jun 20, 2025, Oliver Upton wrote:
On Fri, Jun 20, 2025 at 10:22:32AM -0700, Sean Christopherson wrote:quoted
On Fri, Jun 13, 2025, Oliver Upton wrote:quoted
On Thu, Jun 12, 2025 at 07:34:35AM -0700, Sean Christopherson wrote:quoted
On Thu, Jun 12, 2025, Marc Zyngier wrote:quoted
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@linux.dev/ (local)quoted
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.Marc, does this look and read better? I'd really, really like to get this sorted out asap, as it's the only thing blocking the series, and I want to get the series into linux-next early next week, before I go OOO for ~10 days.Can you just send it out as a standalone patch? It's only tangientally related to the truckload of x86 stuff
The issue is that "KVM: Don't WARN if updating IRQ bypass route fails" directly depends on both this patch and decent chunk of the x86 crud. I could probably trim some of the x86 crud by reshuffling patches around, but I can't get rid of it entirely.
that I'd rather not pull in the event of conflict resolution.
LOL, why not? :-) If I post it as a standalone patch, could you/Marc put it into a stable topic branch based on kvm/master? (kvm/master now has patch 1, yay!) Then I can create a topic branch for this mountain of stuff based on the arm64 topic branch.