From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A89A0606A31E for ; Sun, 15 Nov 2026 18:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=kdMIh4br; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=I4RBcK4Z 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-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=arPSgjHS15vPHb0JCnqy9OouR7YuHrSqzN7k0IpSy4Y=; b=kdMIh4br5I6uxC 3W18xg2OUuY13omWFlY+4m7Dleay+USIC8Iu+xWimK1/MPdcdlsowWAXf5LpJHhNZvqBc6UI2/T1e T4xYI7/B7Tel9oR5T0Z9k92pH+gOkaZIvhJD2/wEpqjJZNb+5tbHgxqFCjyGjwvdqWYwsbxAkAZgX x9y8VuNKE1EUOZEbMAX2Tyt80VGzGw2u3KhMmsdHR1sNbu98g1d1911lnMSfzabPOY5RfenyYyPcq 81p5YtzeXzc0lSCAydq2b4Fyu9p767sVcp19NluLZNS2hPeUx2FB3PgUsFBXRrxtwa9OAbUas+SBK Yy+yG9jRMrazFImDfAiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xSf7l-00000000LSg-13Dr; Sun, 15 Nov 2026 18:38:45 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xSf7j-00000000LSV-3Ryo for linux-arm-kernel@lists.infradead.org; Sun, 15 Nov 2026 18:38:43 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 34C9760DB0; Sun, 15 Nov 2026 18:38:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A63B01F000C4; Sun, 15 Nov 2026 18:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794767922; bh=arPSgjHS15vPHb0JCnqy9OouR7YuHrSqzN7k0IpSy4Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=I4RBcK4ZAnk1QwAXA56mz6tfAD7cwMoY/DmdBdyNp/MCDke1j0K/iqhm2TnulUyRT paudavJLRFoqY3/kXQ6WVI1qOvGarxQU9eZZWzNV5NBqBqZb4NjtiP3ZOCusbJ7AGK KLjVXP0f5GcuKSrk+B5xeMcu4WSIv3e+w2MX9FH06EMoNy5BreKICjuE5d5bobeV4B 7wthe7OE1Dz0rYq6dImjBWzvPgBakFh6KJZk5eJczAreOd3RNl3fOWWFNN7XeL4cNl WkDBLVHUC6lMXJfuspSxAMTsJteDaLTe2gNw5o4N+PdsnPSEyB8lB1bCA1azrx4P0I o+K/AezXHHqyg== Message-ID: Date: Sun, 15 Nov 2026 19:38:35 +0100 X-Archived-By: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 0/6] PSCI-via-EFI to support firmware and kernel sharing EL2 for Apple Silicon To: Ard Biesheuvel , Will Deacon , Mark Rutland Cc: Lorenzo Pieralisi , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Ilias Apalodimas , Catalin Marinas , Sudeep Holla , Janne Grunau , Neal Gompa , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, asahi@lists.linux.dev References: <20260708-efi-psci-v1-0-9efb3abf0e4c@kernel.org> <9c53cfd7-e193-4441-83ca-7710060225b7@app.fastmail.com> Content-Language: en-US From: Sven Peter In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On 03.09.26 15:25, Ard Biesheuvel wrote: > On Thu, 3 Sep 2026, at 14:15, Will Deacon wrote: >> On Thu, Sep 03, 2026 at 12:42:39PM +0100, Mark Rutland wrote: >>> On Thu, Sep 03, 2026 at 01:34:56PM +0200, Ard Biesheuvel wrote: >>>> On Wed, 8 Jul 2026, at 09:15, Sven Peter wrote: >>>>> This series adds a custom EFI table that points to a PSCI entry point >>>>> (plus some other stuff that has to be available before EFI runtime >>>>> services are set up) and adds support for this new conduit to the psci >>>>> code. We can't directly use the normal EFI runtime path because that one >>>>> takes a sleeping lock and we need to be able to call into PSCI from >>>>> atomic context during e.g. cpu bringup or during idle. >>>>> It also adds support for specifying the specific MAIR attributes for EFI >>>>> runtime mappings as defined in the latest UEFI spec since Apple Silicon >>>>> is rather allergic to using Device-nGnRnE vs. Device-nGnRE for its MMIO. >>> >>>>> dt-bindings: arm: psci: Add EFI conduit >>>>> arm64/efi: Add and parse custom PSCI EFI configuration table >>>>> efi: Add EFI_MEMORY_ISA_{MASK,VALID} >>>>> arm64/efi: Honor EFI_MEMORY_ISA_MASK for Device-nGnRnE vs -nGnRE >>>>> firmware/psci: Add EFI runtime conduit >>>>> arm64: dts: apple: t8103: Add PSCI and CPU idle states >>>>> >>>> >>>> I've picked up patches #3 and #4, which are useful in their own right. >>>> >>>> I'm not sure if the arm64 maintainers will want to consider this, but >>>> I think it's a reasonable compromise, as it puts the abstraction in >>>> the right place. >>> >>> Sorry for the late reply; I've been away almost all of August and I'm >>> slowly catching up on things. >>> >>> As with last time this was proposed (in abstract), I am not happy about >>> bodging an EFI conduit into PSCI, given that the manner in which state >>> is managed is completely different from SMCCC. >>> >>> If we need a mechanism for doing hotplug and/or idle without HVC/SMC, >>> that's one thing we can consider. I don't think we should pretend that >>> it is PSCI. >> >> What do you have in mind for an alternative mechanism? I understand your >> objection to this proposal, but at least it keeps the interface fairly >> high-level and avoids opening the flood gates for a bunch of SoC-specific >> idle routines. Are you thinking of extensions to the PSCI spec or >> something else? >> > > I can't speak for Mark, of course, but I could imagine EFI being used as a > conduit to provide a callable set of interfaces (with a rigorously defined > set of constraints such as the ones in this patch, i.e., reentrancy, no FP > or SIMD, not relying on ISA features that the OS needs to know about and > enable, etc). > > There is prior art here in ACPI PRM, which does something similar, and this > also relies on EFI runtime services. > > You'd still need to implement the CPU ops and a cpuidle driver afaict (no > expert here), but at least those would be coded against an interface that > the kernel itself specified, and can be made as generic as we choose to. > > Not saying this is all great, but it might be a worthwhile compromise to > consider. Finally getting back to this series... I'd definitely like to keep mapping the resident firmware using EFI runtime services because otherwise I'd have to duplicate a whole lot of tricky code to do the same thing via some other means (e.g. a device tree nodes that contains all mappings + callbacks) and I just don't see much value in that. I'm happy to just drop the PSCI part though and replace that with a simple and somewhat generic "efi-rt" (or similar) cpuidle driver and make that one have similar requirements like I added for this RFC series and expose bunch of generic callbacks (that will just happen to resemble PSCI functions very much ;)) via a custom EFI table. That would keep PSCI out of all of this but come at the cost of an additional cpuidle driver. I don't think that would open any flood gates for SoC-specific drivers since we could just point them to the generic one and tell them to use that one if they can't do PSCI for some reason. Now before I go off and prototype this: Would this approach be fine in general with you, Mark and Will? Sven