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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B075CC3DA7F for ; Thu, 15 Aug 2024 09:33:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3gfhzgUPNgw9HAQwwI0Eji9A+MXiFoOJo/b8uxfOZQ4=; b=pElEt1rqO9RcHMCEVGipD2TuKE OXwQ2XK2zagMdVop5Y0MNIQ3Mx7bKuJGs5+zg2fzdEwHJu7z8A9yqLAo7CWmSAPILOTkM+2OZvwRb ixydqHxaqNHwaDSKNUFkWbYpkVkbSlChtnfVraMQcPKoWVcUdFcHvB2JoIkAvUbKDabp6FbAWIlQ/ 7H2astpm0gWaKVNSab+sVUMJ7WizrxUVcd1oUIWup5vn+5uajQLQdr6/oEEwhTC8Fce8uG1MYIcDa paaHS12yKnboXkz7n86Xkz4rL+z2Pvd72bJgNhaUTLr5ORPl+CUHLAGLB7T0hiFBIwprSRwO/lhbE ZMzbZcow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seWrb-00000009Uj6-3dME; Thu, 15 Aug 2024 09:33:47 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seWqy-00000009Ues-2ziD for linux-arm-kernel@lists.infradead.org; Thu, 15 Aug 2024 09:33:10 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 02C6561961; Thu, 15 Aug 2024 09:33:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2BD5C32786; Thu, 15 Aug 2024 09:33:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723714387; bh=YiYZidn1idmYV57lmRj2Oy4O0BfPjV/4Sf952NuF1NY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MA4ZDSzdiG09znu0W6odTW1qjdCTZcUfV6+u1HQ4iu9ADpvZkpsI0l14y6MdQsMJ1 9fFN+8mcV1sz3BKsrIzuafcnRH1lB3NE0ojdSsKUsFWsjENPN1zSP+phRSu2CMKZKy 3rssF49nhbMt7YkwZQsiGYy/clG9ZaL8p5/p3DBNDliURV2nJ/zOYYu/6NSi0b1xXX 09Ad6lTxTIKqhRdb9YyEb2/M57doYnIP2RGbisG2n6NOWgv0AE3Chzy6Ug1Rz/mVsn ag5dWOVwKjST30V9zLH+sATXcnqG5ECxvcimsPR5Vtz5C2DK7tqg6MTHm/+pvVd/Ev Bhf1M4hNN8rRw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1seWqv-003ugc-Iu; Thu, 15 Aug 2024 10:33:05 +0100 Date: Thu, 15 Aug 2024 10:33:05 +0100 Message-ID: <86plqayvu6.wl-maz@kernel.org> From: Marc Zyngier To: Sudeep Holla Cc: Shanker Donthineni , Thomas Gleixner , Catalin Marinas , Will Deacon , Jonathan Corbet , , Subject: Re: [PATCH] irqchip/gic-v3: Allow unused SGIs for drivers/modules In-Reply-To: References: <20240813033925.925947-1-sdonthineni@nvidia.com> <86zfpgztmt.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/29.4 (aarch64-unknown-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: sudeep.holla@arm.com, sdonthineni@nvidia.com, tglx@linutronix.de, catalin.marinas@arm.com, will@kernel.org, corbet@lwn.net, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org 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-20240815_023308_865529_5C08854B X-CRM114-Status: GOOD ( 30.78 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 13 Aug 2024 11:33:47 +0100, Sudeep Holla wrote: > > On Tue, Aug 13, 2024 at 09:58:34AM +0100, Marc Zyngier wrote: > > No. This is the wrong approach, and leads to inconsistent behaviour if > > we ever change this MAX_IPI value. It also breaks 32 bit builds, and > > makes things completely inconsistent between ACPI and DT. > > > > I don't know how the FFA code was tested, because I cannot see how it > > can work. > > > > *IF* we are going to allow random SGIs being requested by random > > drivers, we need to be able to do it properly. Not as a side hack like > > this. > > I am open for any ideas as FF-A spec authors/architects decided to allow > secure world to donate one of its SGI to the normal world for FF-A > notifications. Let's first try to answer a simple question: how is that going to work for interrupt architectures that do not have the concept of SGIs, but rely on normal interrupts (similar to SPIs or LPIs) for their IPIs? They don't have a global interrupt number per CPU for their IPIs, and may not even have the concept of a shared numbering space between security domains. This makes the whole concept of "delegating" an interrupt number from secure to non-secure a dead-end. Should we build a SW ecosystem on that? The other thing is: if FFA is exposing interrupts to be signalled from secure to non-secure, and that it insists on using SGIs, why isn't that described in DT/ACPI, with a reservation mechanism that would allow the GIC driver to reserve the corresponding SGI and not dish it out as a normal mechanism? Because this sort of thing + if (acpi_disabled) { + struct of_phandle_args oirq = {}; + struct device_node *gic; + + /* Only GICv3 supported currently with the device tree */ + gic = of_find_compatible_node(NULL, NULL, "arm,gic-v3"); + if (!gic) + return -ENXIO; + + oirq.np = gic; + oirq.args_count = 1; + oirq.args[0] = sr_intid; + irq = irq_create_of_mapping(&oirq); + of_node_put(gic); +#ifdef CONFIG_ACPI + } else { + irq = acpi_register_gsi(NULL, sr_intid, ACPI_EDGE_SENSITIVE, + ACPI_ACTIVE_HIGH); +#endif + } is an absolute howler. It is abusing the arch-private interface, is at the mercy of buggy EL3 returning stupid values, and may tramp over the kernel's own IPI allocation. All these problems need to be addressed. Thanks, M. -- Without deviation from the norm, progress is not possible.