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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 DFE8FC4338F for ; Tue, 3 Aug 2021 08:37:15 +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 A49EE60F58 for ; Tue, 3 Aug 2021 08:37:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A49EE60F58 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com 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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Lm5BSc+jyNQgPtpP3fsgGgQW9ReQ4BJtsnOeD2KhvxA=; b=KW3ZYwmnjVut85uvtJGW7TN8KR fEo1RW+Z83akGgvyVzuxMSeFLDG69qlkP8NIBhVedZ126dkDk8rG/gOS/7+7R/9/IMwmQ56xiZpFg TwAKJvPliPrrDHD25q4BPz20DkACGYwIMEcUeJgozPxl3zX6mUPNcXx0kW4+kNlvM/zb8q7huaZEu ouT7tR/X1q8h0c0wTwUx0qc1hvs3x2Tw00c+O/RiHo2yZjeWsdghXNjurYSTHZDIOcEpFX2VJQaJw pggkK89gYT6HYcvvsPwVPK9Vr15BwGvWRlfqjmb6jyWJSlZC9Ayz7IJsLOetrcLws/toxRjGjC0wW Mced4+sA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAptW-001dJ9-On; Tue, 03 Aug 2021 08:35:26 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mAptS-001dIZ-Cy for linux-arm-kernel@lists.infradead.org; Tue, 03 Aug 2021 08:35:24 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 376B1D6E; Tue, 3 Aug 2021 01:35:20 -0700 (PDT) Received: from [10.57.36.146] (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 785AE3F70D; Tue, 3 Aug 2021 01:35:18 -0700 (PDT) Subject: Re: [EXTERNAL] Re: [RFC 1/1] irqchip/gic-v3-its: Add irq domain and chip for Direct LPI without ITS To: Sunil Muthuswamy , Marc Zyngier 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 References: <87a6mt2jke.wl-maz@kernel.org> <87tuka24kj.wl-maz@kernel.org> From: Robin Murphy Message-ID: Date: Tue, 3 Aug 2021 09:35:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210803_013522_596357_E4964995 X-CRM114-Status: GOOD ( 28.62 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-08-03 03:11, Sunil Muthuswamy wrote: > On Saturday, July 31, 2021 2:52 AM, > Marc Zyngier 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. >> > I am a little bit confused by your above comment. Maybe you can help me > understand the ask. You indicate that from the point of the view of the > device, all the RDs should be reachable. But, then if we define a mapping > between PCI endpoint and RD in the firmware, we would be doing exactly > the opposite. i.e. restricting the RDs that are reachable by the device. Can > you please clarify? > > Is your concern that the device should be able to only DMA to a subset of > GIC Redistributor, for the MSIs? If so, in the IORT, there is "memory address > size limit" for both device and root complex nodes. In the implementation, > we can enforce that the GICR is within that range. And, if a device deviates > further than that (ex: by having accessibility gaps within the GICR range), > then that is out of scope for support. No, please don't try to abuse the Memory Address Size Limit - that has far more chance of adversely affecting normal DMA operation than of being any use here. I believe the point Marc was trying to make is that firmware should not associate a device with any one *specific* redistributor, however ACPI currently has no way to describe that MSIs can target redistributors *at all*, only ITS groups - there is no such concept as a "redistributor group". Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel