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 3C696C4332F for ; Sat, 4 Nov 2023 10:30: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: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tiUT6ytF9rAtrbzKZj0iFFjYXg19bIjkrfUXCF5FTh8=; b=e1X5L1SMPPXN4c q4AKhZv3H6qI6LgodhVxutIUQFu89Wh4ZxicckTMeaWqf+IZGALwBiCoK2IGIRwefE2hij7ZkrkRJ 1kcKCXsC5GlNTjDrV9itZhqbfui5rIAbtzhvMT1yOkEyo64VzT1uv1xkbdyEJYdkYVlzeLgbD5ZjN ts/AALnL1SjI/B4Q4p7tn6FA46QsN51HG5Ue1yuRIN/xx/xM8g/P/TzYxSYsBsk47NS6F27aN6ZsS qiWqRV4ncEugHecu8OzgzwK3LsSbPD2g12PJyJjbEHKYuDQ6VYz/v7WHVnqME+xld8ICFl7yYii/d 7tYtbP99lKRTZNAAEJNA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qzDuK-00D23U-1A; Sat, 04 Nov 2023 10:29:36 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qzDuH-00D21t-0D for linux-arm-kernel@lists.infradead.org; Sat, 04 Nov 2023 10:29:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1FF5D60B61; Sat, 4 Nov 2023 10:29:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC9D5C433C8; Sat, 4 Nov 2023 10:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699093771; bh=HXRzsIFHO/MkPFHEkPUzGw3ej4iVJA/za+qQPnx3lhk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AsQnnICXke91U8EZ0e5f9vW3Sa3TaHQvUPsIkgrrkjbaCH1bMZuVJ+AAWlMgECZB9 R2tIKD7BZTCNmyzt2R0I8WfGsH8rExvdKRLa4ttg6BYtM6A05fLxTep/vXq29wiJak iFo2uA6JSkUPwnY9ZWkITjwU8jaYNADHqV15Lg/Gb0qDAt6Yfg3AqVDjmiGc4ptaQB sfghgRuPi0HOA8+Mp8kEabwytj40omqJaP7zMiQZh4jVSpx5iK3r/YxKVZ9iXwujMY 4AViMXODWhklwqfyKQY0egRmJRPnJ/7MKLyTix18vKvACgc5Tp76NtR/pryFlGKqlD K1ZGtLe5nVISA== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qzDuD-00AHV1-BF; Sat, 04 Nov 2023 10:29:29 +0000 Date: Sat, 04 Nov 2023 10:29:28 +0000 Message-ID: <87msvt6cc7.wl-maz@kernel.org> From: Marc Zyngier To: Kunkun Jiang Cc: Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Gavin Shan , Jean-Philippe Brucker , "open list:IRQCHIP DRIVERS" , , , Subject: Re: [RFC PATCH] KVM: arm/arm64: GICv4: Support shared VLPI In-Reply-To: <20231102143507.840-1-jiangkunkun@huawei.com> References: <20231102143507.840-1-jiangkunkun@huawei.com> 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/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jiangkunkun@huawei.com, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, gshan@redhat.com, jean-philippe@linaro.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, wanghaibin.wang@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231104_032933_248842_0F33D3C3 X-CRM114-Status: GOOD ( 26.50 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 02 Nov 2023 14:35:07 +0000, Kunkun Jiang wrote: > > In some scenarios, the guest virtio-pci driver will request two MSI-X, > one vector for config, one shared for queues. However, the host driver > (vDPA or VFIO) will request a vector for each queue. Well, VFIO will request *all* available MSI-X. It doesn't know what a queue is. > > In the current implementation of GICv4/4.1 direct injection of vLPI, > pINTID and vINTID have one-to-one correspondence. Therefore, the This matching is a hard requirement that matches the architecture. You cannot change it. > above scenario cannot be handled correctly. The host kernel will > execute its_map_vlpi multiple times but only execute its_unmap_vlpi > once. This may cause guest hang[1]. Why does it hang? As far as it is concerned, it has unmapped the interrupts it cares about. Where are the calls to its_map_vlpi() coming from? It should only occur if the guest actively programs the MSI-X registers. What is your VMM? How can I reproduce this issue? > > | WARN_ON(!(irq->hw && irq->host_irq == virq)); > | if (irq->hw) { > | atomic_dec(&irq->target_vcpu->arch.vgic_cpu.vgic_v3.its_vpe.vlpi_count); > | irq->hw = false; > | ret = its_unmap_vlpi(virq); > | } > > Add a list to struct vgic_irq to record all host irqs mapped to the vlpi. > When performing an action on the vlpi, traverse the list and perform this > action on all host irqs. This makes no sense. You are blindly associating multiple host interrupts with a single guest interrupt. This is a blatant violation of the architecture. When unmapping a VLPI from a guest, only this one should be turned again into an LPI. Not two, not all, just this one. Maybe you have found an actual issue, but this patch is absolutely unacceptable. Please fully describe the problem, provide traces, and if possible a reproducer. > > Link: https://lore.kernel.org/all/0d9fdf42-76b1-afc6-85a9-159c5490bbd4@huawei.com/#t I tried to parse this, but it hardly makes sense either. You seem to imply that the host driver pre-configures the device, which is completely wrong. The host driver (VFIO) should simply request all possible physical LPIs, and that's all. It is expected that this requesting has no other effect on the HW. Also, since your guest driver only configures a single vLPI, there should be only a single its_map_vlpi() call. So it seems to me that your HW and SW are doing things that are not expected at all. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel