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, URIBL_BLOCKED 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 468B9C432BE for ; Tue, 10 Aug 2021 13:59:50 +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 DB64B60FDA for ; Tue, 10 Aug 2021 13:59:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DB64B60FDA 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=rd1jPjhX1Ghu5aqUXd7N03jjDcBiYT62LNf/5mynu5M=; b=GdpF55GxwOoTqy QzUNU5CCRB8cQ53SDQJ4Y4uj2lQnNslN044zzQyc39orjmn0/iC5JXtUC0L9OrKlKFyJ/2Q1n88od HJZ3yOsERqp9Ni+vpyo+Pi9YgjHSEfoNb5Ux7K2g0BYYYZPuroGp5Z6vyBagtdYiqZINBqtTrJdwv XBQZh9F3pfXLBq3kChK4ruFS8TWWd8ywdkB5PS/5yFEuyzW5pF2Q3bQm9m2ARxqvOiLHEIZrH0oKW clxTODMEc284A44KWsa5uXudxkPT4CUQmkTiSI2MlzV6GjIa4DDaYXh2lr8tlDzDRxpTKLlFgFsD/ 9jgtt7k0Io4DZp3BUkqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDSFk-0044iq-L4; Tue, 10 Aug 2021 13:57:12 +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 1mDSFg-0044hc-TP for linux-arm-kernel@lists.infradead.org; Tue, 10 Aug 2021 13:57:10 +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 9812160295; Tue, 10 Aug 2021 13:57:08 +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 1mDSFe-0044bF-L3; Tue, 10 Aug 2021 14:57:06 +0100 Date: Tue, 10 Aug 2021 14:57:06 +0100 Message-ID: <8735rhbdxp.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> <87pmunasik.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-20210810_065709_032443_73948F2E X-CRM114-Status: GOOD ( 33.30 ) 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 Tue, 10 Aug 2021 02:10:40 +0100, Sunil Muthuswamy wrote: > > On Monday, August 9, 2021 2:15 AM, > Marc Zyngier wrote: > [...] > > 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. > > > Ok, thanks. Before we commit to anything, I would like to make sure > that I am on the same page in terms of your description. With that in > mind, I have few questions. Hopefully, these should settle the matter. > 1. If we go with the SPI route, then the way I envision it is that the > Hyper-V vPCI driver will implement an IRQ chip, which will take > care of allocating & managing the SPI interrupt for Hyper-V vPCI. > This IRQ chip will parent itself to the architectural GIC IRQ chip for > general interrupt management. Does that match with your > understanding/suggestion as well? Yes. > > 2. In the above, how will Hyper-V vPCI module discover the > architectural GIC IRQ domain generically for virtual devices that > are not firmware enumerated? Today, the GIC v3 IRQ domain is > not exported and the general 'irq_find_xyz' APIs only work for > firmware enumerated devices (i.e. something that has a fwnode > handle). You don't need to discover it with ACPI. You simply instantiate your own irqdomain using acpi_irq_create_hierarchy(), which will do the right thing. Your PCI driver will have to create its own fwnode out of thin air (there is an API for that), and call into this function to plumb everything. > > 3. Longer term, if we implement LPIs (with an ITS or Direct LPI), to > be able to support all scenarios such as Live Migration, the > Hyper-V virtual PCI driver would like to be able to control the > MSI address & data that gets programmed on the device > (i.e. .irq_compose_msi_msg). We can use the architectural > methods for everything else. Does that fit into the realm of > what would be acceptable upstream? I cannot see how this works. The address has to match that of the virtual HW you target (whether this is a redistributor or an ITS), and the data is only meaningful in that context. And it really shouldn't matter at all, as I expect you don't let the guest directly write to the PCI MSI-X table. If you let the guest have access direct to that table (which seems to contradict your "live migration" argument), then your best bet is to use provide a skeletal IOMMU implementation, and get iommu_dma_compose_msi_msg() to do the remapping. But frankly, that's horrible and I fully expect the IOMMU people to push back (and that still doesn't give you any control over the data, only the address). 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