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 X-Spam-Level: X-Spam-Status: No, score=-4.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04C26C4338F for ; Sun, 8 Aug 2021 10:21:42 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AFC3361004 for ; Sun, 8 Aug 2021 10:21:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AFC3361004 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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=yMHUexnZNJefNwF8U8sGQhhMefoGO41vqxR8TTdQxkQ=; b=oiq3IFRP5k5BNx aShjBg0VohybVIxUjRTdZCJwmLIO+iTlSiWQU2fQyerQRRhO7clWdYpQKO4hpPZ4HD0BEHYsKNcdr 5dm0NMnjbqkLkoYwfpmBGLGfHAi87Twd0yRPoCBjjs4OldBLxhMcNt/SijHGgYARMBkVrYrRd36aE GleW2Dcmd3K0qXcb+84KGjn38Is3qtlT7c9iJDVmjofX4Hi6U3s4OZxj/JGq/ceaYCL3/qd21JBh+ tPF7TPTJ5AQXS2f45ZEgXRc2LlgMigdlw1g54OTahqgrit2OBQTAfTe5ZOpvCAqp4SZUqKIP3+j9y WiA4mSuzv3EfdWyo37hw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mCftk-00FiRe-5f; Sun, 08 Aug 2021 10:19:16 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mCftg-00FiRE-RY for linux-arm-kernel@lists.infradead.org; Sun, 08 Aug 2021 10:19:14 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2576361004; Sun, 8 Aug 2021 10:19:12 +0000 (UTC) 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.94.2) (envelope-from ) id 1mCfte-003cJ1-5e; Sun, 08 Aug 2021 11:19:10 +0100 Date: Sun, 08 Aug 2021 11:19:09 +0100 Message-ID: <87o8a81boi.wl-maz@kernel.org> From: Marc Zyngier To: Sunil Muthuswamy Cc: Robin Murphy , Thomas Gleixner , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "catalin.marinas@arm.com" , "will@kernel.org" , Michael Kelley , Boqun Feng , KY Srinivasan , Arnd Bergmann , Lorenzo Pieralisi Subject: Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS In-Reply-To: References: <87a6mt2jke.wl-maz@kernel.org> <87tuka24kj.wl-maz@kernel.org> <87r1f9wooc.wl-maz@kernel.org> <87wnp0b86y.wl-maz@kernel.org> 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/27.1 (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: sunilmut@microsoft.com, robin.murphy@arm.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, mikelley@microsoft.com, Boqun.Feng@microsoft.com, kys@microsoft.com, arnd@arndb.de, lorenzo.pieralisi@arm.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-20210808_031912_970464_9E410205 X-CRM114-Status: GOOD ( 40.51 ) 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 Fri, 06 Aug 2021 20:14:13 +0100, Sunil Muthuswamy wrote: > > On Thursday, August 5, 2021 1:35 AM, > Marc Zyngier wrote: > [...] > > > Hey Mark > > > > I assume this is for me? > > > Yes, sorry. > > > > would you be willing to consider a scoped down implementation of GIC > > > Direct LPI with just an IRQ chip implementation and no Direct LPI > > > PCI-MSI IRQ chip. > > > > Could you please clarify? If you are not implementing MSIs, how can a > > device signal LPIs? At the end of the day, something has to write into > > the RD, and it isn't going to happen by sheer magic. > > > > > This will allow a MSI provider (such as Hyper-V vPCI) to provide a > > > PCI-MSI IRQ chip on top of the Direct LPI IRQ chip and enable > > > PCI-MSI scenarios, and avoid building in assumptions in other cases > > > (like PCI) where firmware specification is not available. > > > > I really don't get what you are suggesting. Could you please describe > > what you have in mind? > > > The suggestion was to *not* implement the PCI-MSI IRQ chip in the > Direct LPI GIC implementation, but let the endpoint/specific > implementation provide for the MSI IRQ chip. > > For example, the Hyper-V vPCI module does implement a PCI-MSI IRQ > chip (refer to 'hv_pcie_init_irq_domain'). Microsoft Hypervisor > provides/virtualizes the MSI address to be used for Hyper-V vPCI. The > Hypervisor might be using the ITS in the background, but it expects > the device to be programmed with the MSI address that it provides. > And, the Hypervisor takes care of routing the interrupt to the guest. > This is done by the Hyper-V vPCI MSI IRQ chip (refer to > hv_msi_irq_chip) compose MSI message. > > Today, for X64, Hyper-V vPCI PCI-MSI irq chip parents itself to the > architectural 'x86_vector_domain'. The suggestion here was to see > if we can support a similar setup for ARM, where the Hyper-V vPCI > PCI-MSI irq chip can parent itself to the 'Direct LPI arch IRQ chip' > (to be implemented). > > The arch Direct LPI arch IRQ chip is needed to enable LPIs, invalidate > the LPI configuration (GICR_INVLPIR et. al. ) and allocate LPI IRQs from > the LPI interrupt namespace (i.e. 8192-). > > Happy to expand on this further, if the above is not clear. [+Lorenzo, as he deals with both PCI and ACPI] I think it is clear enough, but I don't see what this buys us other than turning DirectLPI into something that is essentially private to Hyper-V, just for the sake of sidestepping a firmware description. Furthermore, the Hyper-V "single MSI address" model doesn't match the way DirectLPI works (after all, this is one of the many reasons why we have the ITS). The architecture already gives you everything you need to make things work in Hyper-V. You can easily implement the DirectLPI support (you definitely need most of it anyway), and the PCI-MSI layer is *free*. All you need is a firmware description. Which I don't believe is the end of the world, given that DT is freely hackable and that IORT is an ARM-private extension to ACPI. I'm sure you know who to reach out to in order to start a draft (and if you don't, I can give you names offline). I am not interested in expanding the GICv3 architecture support if it cannot be generally used in a way that is *compliant with the architecture*. If you think DirectLPIs can make the hypervisor simpler, I'm fine with it. But let's fully embrace the concept instead of hiding it behind a layer of PV muck. It will even have a chance of working on bare metal (such as on the machine that is humming behind me, or even the Fast Model). Thanks, 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