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.0 required=3.0 tests=BAYES_00,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 B6501C4338F for ; Mon, 9 Aug 2021 09:15:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 97DDC61078 for ; Mon, 9 Aug 2021 09:15:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234245AbhHIJPj (ORCPT ); Mon, 9 Aug 2021 05:15:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:33334 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234157AbhHIJPi (ORCPT ); Mon, 9 Aug 2021 05:15:38 -0400 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 322D560F02; Mon, 9 Aug 2021 09:15:18 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1mD1NM-003mK7-0J; Mon, 09 Aug 2021 10:15:16 +0100 Date: Mon, 09 Aug 2021 10:15:15 +0100 Message-ID: <87pmunasik.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> <87o8a81boi.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") Content-Type: text/plain; charset=US-ASCII 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 09 Aug 2021 03:35:05 +0100, Sunil Muthuswamy wrote: > > Sunday, August 8, 2021 3:19 AM, > Marc Zyngier wrote: > > > > [+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). > > > That sounds reasonable. The DT extension here alone wont suffice for > Hyper-V and we would need the ACPI IORT extension here as well. Our > general experience with ACPI extension is that they can take time. But, > I am curious to hear from Lorenzo on his thoughts here and if just an > IORT extension means anything else in terms of timelines. > > > 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). > > > Appreciate your inputs. Since we are discussing options, there is one more > option to enable Hyper-V virtual PCI for ARM64 that I do would like to > discuss. That option is to implement the IRQ chip completely within the > Hyper-V module itself. That IRQ chip will take care of allocating LPI vectors, > enabling the interrupt (unmask, mask etc..). It won't be a Direct LPI based, > but based on custom Hyper-V methods. That chip will parent itself to the > GIC v3 IRQ domain. The only extra thing needed for this is for the Hyper-V > IRQ chip to be able to discover the GIC v3 IRQ domain, for which it > cannot use the 'irq_find_matching_fwnode' method as Hyper-V virtual > PCI bus/devices are not firmware enumerated. I am not sure if there is any > other way to discover the GIC (DOMAIN_BUS_WIRED) domain. > > What are your thoughts/feedback on the above? This will allow us to > enable the scenario for the business timelines we are targeting for, while > we wait for firmware spec updates. Long term we also want to use > architectural methods here as that helps the Hypervisor as well, and I > would be glad to pursue the firmware spec updates in parallel. This feels like yet another layer of PV ugliness that has the side effect of fragmenting the architectural support. If you plug directly into the GICv3 layer, I'd rather you inject SPIs, just like any other non-architectural MSI controller. You can directly interface with the ACPI GSI layer for that, without any need to mess with the GICv3 internals. The SPI space isn't very large, but still much larger than the equivalent x86 space (close to 1000). If time is of the essence, I suggest you go the SPI way. For anything involving LPIs, I really want to see a firmware spec that works for everyone as opposed to a localised Hyper-V hack. Thanks, M. -- Without deviation from the norm, progress is not possible.