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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A738C4167D for ; Sat, 4 Nov 2023 10:29:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231931AbjKDK3g (ORCPT ); Sat, 4 Nov 2023 06:29:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231824AbjKDK3e (ORCPT ); Sat, 4 Nov 2023 06:29:34 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3726F191 for ; Sat, 4 Nov 2023 03:29:32 -0700 (PDT) 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") Content-Type: text/plain; charset=US-ASCII 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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.