From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6B6A6CA9ED0 for ; Mon, 12 Oct 2026 11:19:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lK+qV6ACE+ZIC7/SKRa3Jojmx9oqGAXfttgxOcfCiug=; b=JETfnnEVUryK34WGcVrgV+rvDh iPya/C3/nEbka+6r5erWEFauwr77HWpBEyELLdh7gH6l9hLWsx+IgZjX2QE7/CUfKpBa7EpBtUIuq ZcOkeK5tYMQhqIBJYzBXaUyX1yiPG8nBBTxhVGWB7N5DkIwQbDxrqnodzjHtnNMmofEUQ+CqFUsvQ mpaOyt7wxUhWaoMJ0GcWPASSaV0xXmFdT/+29Hmb2CHo4upn8GCIQyPuZSLk2kCgt1p6WgNGNVedG qdF4dhXOip3VTJ73c3UqQLlAAawjyEcjTZd0jRyGSqhxT+29xhryWrQti9qvG9nH7gh9Hu4V7SfCA LIzUYLDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xGE3U-0000000AKyI-2QN9; Mon, 12 Oct 2026 11:18:56 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xGE3T-0000000AKy1-3Wbn for linux-arm-kernel@lists.infradead.org; Mon, 12 Oct 2026 11:18:55 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 036C9601FE; Mon, 12 Oct 2026 11:18:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB2221F0089B; Mon, 12 Oct 2026 11:18:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791803934; bh=lK+qV6ACE+ZIC7/SKRa3Jojmx9oqGAXfttgxOcfCiug=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=GCxHvs/X+x/620NMpUjYsEgKKYPzCd8nvloW+GB/wUHrYBgnzpkeqkqknm4IAy1C9 oZSTQViurCAm2XPhplhdaVVuWflpOeU1vPArVp92GEWGoWdnfihy7FghMtsTnSbFcf 5AkJDD4NaXQtK/efkWAt430AdYv2bSI1AB5OIyq6GVCBbnkaNQcyplMnMvpD7JQI5s OoaeYKmsqddZCUa3o83Uz/QuGKYKAueN+qLX+JvYz39qkKpgImLnofvwdRhFnOZN5v reefTqZh70dZwB57nq2q+mS/0ojfJJD+xPMKHZOuz63/Wt1IL6oYjGrlrf3Pv5r13b SkEze+R0ZC08g== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xGE3Q-00000001qdE-21hE; Mon, 12 Oct 2026 11:18:52 +0000 Date: Mon, 12 Oct 2026 12:18:51 +0100 Message-ID: <8633ub2mlg.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: Oliver Upton , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, Fuad Tabba Subject: Re: [PATCH v1] KVM: arm64: vgic-v4: Don't forward an LPI with no target vCPU In-Reply-To: <20261012084743.2228612-1-fuad.tabba@linux.dev> References: <20261012084743.2228612-1-fuad.tabba@linux.dev> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: fuad.tabba@linux.dev, oupton@kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, tabba@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 12 Oct 2026 09:47:43 +0100, Fuad Tabba wrote: > > KVM keeps one vgic_irq per LPI. The MAPTI that creates it sets its > target vCPU from that MAPTI's collection, and a later MAPTI of the same > LPI leaves the target alone. Mapping one LPI from two events is > UNPREDICTABLE (IHI 0069H.b, 5.2.10), but nothing stops a guest doing > it. If the first MAPTI names a collection the guest never maps and the > second a mapped one, the LPI translates through the second event with > a NULL target vCPU. > > When the VMM routes an assigned device's MSI to that event on a host > with GICv4 enabled, kvm_vgic_v4_set_forwarding() takes the vPE from the > NULL target vCPU and the host oopses: > > Unable to handle kernel paging request at virtual address 0000000000001980 > [...] > Call trace: > its_build_vmapti_cmd (drivers/irqchip/irq-gic-v3-its.c:943) (P) > its_irq_set_vcpu_affinity (drivers/irqchip/irq-gic-v3-its.c:1380) > irq_set_vcpu_affinity (kernel/irq/manage.c:670) > its_map_vlpi (drivers/irqchip/irq-gic-v4.c:326) > kvm_vgic_v4_set_forwarding (arch/arm64/kvm/vgic/vgic-v4.c:485) > kvm_arch_irq_bypass_add_producer (arch/arm64/kvm/arm.c:2977) > irq_bypass_register_consumer (virt/lib/irqbypass.c:44) > kvm_irqfd (arch/arm64/kvm/../../../virt/kvm/eventfd.c:496) > kvm_vm_ioctl (arch/arm64/kvm/../../../virt/kvm/kvm_main.c:5270) > > Leave such an LPI to the software path, which copes with a NULL target, > as kvm_vgic_v4_set_forwarding() already does when the MSI doesn't > translate. > > Fixes: 196b136498b35 ("KVM: arm/arm64: GICv4: Wire mapping/unmapping of VLPIs in VFIO irq bypass") > Cc: stable@vger.kernel.org > Signed-off-by: Fuad Tabba > --- > Tested on QEMU, which emulates the GICv4 ITS, with a local reproducer > that sets up the two MAPTIs and forwards a vfio-pci MSI to the LPI. It > oopses without the fix and passes with it. Not tested on GICv4 hardware. > > Based on v7.3-rc3. > > arch/arm64/kvm/vgic/vgic-v4.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c > index ed236f083f0d7..545e55317c863 100644 > --- a/arch/arm64/kvm/vgic/vgic-v4.c > +++ b/arch/arm64/kvm/vgic/vgic-v4.c > @@ -466,6 +466,13 @@ int kvm_vgic_v4_set_forwarding(struct kvm *kvm, int virq, > if (irq->hw) > goto out_unlock_irq; > > + /* > + * Silently exit if the LPI has no target vCPU, as one mapped by > + * multiple ITEs (UNPREDICTABLE) can have. > + */ > + if (!irq->target_vcpu) > + goto out_unlock_irq; > + > /* > * Emit the mapping request. If it fails, the ITS probably > * isn't v4 compatible, so let's silently bail out. Holding > Isn't the core problem that we don't correctly handle the UNPRED double mapping of the same LPI? I'd rather we attack the issue at the source instead of papering over the consequences. I hacked the following, which is obviously untested. Can you give it a go? Thanks, M. diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c index e5657cb603567..f0a1a879d9ac1 100644 --- a/arch/arm64/kvm/vgic/vgic-its.c +++ b/arch/arm64/kvm/vgic/vgic-its.c @@ -73,14 +73,16 @@ static int update_lpi_config(struct kvm *kvm, struct vgic_irq *irq, * If this is a "new" LPI, we allocate and initialize a new struct vgic_irq. * This function returns a pointer to the _unlocked_ structure. */ -static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid, - struct kvm_vcpu *vcpu) +static struct vgic_irq *__vgic_add_lpi(struct kvm *kvm, u32 intid, + struct kvm_vcpu *vcpu, bool *created) { struct vgic_dist *dist = &kvm->arch.vgic; struct vgic_irq *irq = vgic_get_irq(kvm, intid), *oldirq; unsigned long flags; int ret; + *created = false; + /* In this case there is no put, since we keep the reference. */ if (irq) return irq; @@ -133,6 +135,8 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid, if (oldirq && !WARN_ON_ONCE(refcount_read(&oldirq->refcount))) kfree_rcu(oldirq, rcu); + + *created = true; } xa_unlock_irqrestore(&dist->lpi_xa, flags); @@ -160,6 +164,25 @@ static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, u32 intid, return irq; } +static struct vgic_irq *vgic_add_lpi(struct kvm *kvm, int lpi_nr, struct kvm_vcpu *vcpu) +{ + struct vgic_irq *irq; + bool created; + + irq = __vgic_add_lpi(kvm, lpi_nr, vcpu, &created); + + /* + * Mapping an LPI twice is UNPREDICTIBLE. Drop mapping an + * existing LPI on the floor and convert it into an error. + */ + if (irq && !IS_ERR(irq) && !created) { + vgic_put_irq(kvm, irq); + irq = ERR_PTR(-EEXIST); + } + + return irq; +} + /** * struct vgic_its_abi - ITS abi ops and settings * @cte_esz: collection table entry size -- Without deviation from the norm, progress is not possible.