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 E2FD3C4338F for ; Sat, 31 Jul 2021 09:52:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C63EB60FE7 for ; Sat, 31 Jul 2021 09:52:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232868AbhGaJwh (ORCPT ); Sat, 31 Jul 2021 05:52:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:60102 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231853AbhGaJwg (ORCPT ); Sat, 31 Jul 2021 05:52:36 -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 A3DB861019; Sat, 31 Jul 2021 09:52:30 +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 1m9lfQ-0029m9-Jl; Sat, 31 Jul 2021 10:52:28 +0100 Date: Sat, 31 Jul 2021 10:52:28 +0100 Message-ID: <87tuka24kj.wl-maz@kernel.org> From: Marc Zyngier To: Sunil Muthuswamy Cc: 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 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> 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, 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 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, 26 Jul 2021 16:33:39 +0100, Sunil Muthuswamy wrote: [...] > > I also want to understand *how* you are going to plumb this into both > > ACPI and DT, given that neither understand how to link a PCI endpoint > > to a set of RDs. > > > > M. > > One way to do this for NUMA-aware systems would be to use the NUMA > related information that is available with PCI endpoints or root complex, to > pick a Redistributor/CPU that is in the NUMA node, as specified by the PCI > endpoint/root complex. In DT PCI devices can specify this using > 'numa-node-id' and in ACPI using the '_PXM (Proximity)'. For systems that > are not NUMA-aware, we can go with *any* Redistributor/CPU. This makes zero sense. From the point of view of a device, all the RDs should be reachable, and firmware has no say in it. Dealing with interrupt affinity is the responsibility of the endpoint driver, and NUMA affinity is only a performance optimisation. > Is there any additional information we would be able to gather from ACPI > or DT that's not there currently, that would be useful here? You will need some firmware information describing that a given set of devices must use the RDs for their MSIs. Just like we currently describe it in IORT for the ITS. You cannot /assume/ things. At the moment, there is nothing at all, because no-one (including Microsoft) thought it would be a good idea not to have an ITS, which is also why ACPI doesn't describe MBIs as a potential MSI provider. > The other question is, what DT property can be used to instantiate the > PCI-MSI IRQ domain for Direct LPI? As per the DT spec, there is only > 'msi-controller' Sub-node for the ITS. Read again. We already a msi-controller property in the main GICv3 node for the purpose of MBIs. You can reuse this property, but you will have to discriminate whether you want MBIs or DirectLPIs with some extra property. M. -- Without deviation from the norm, progress is not possible.