Re: [PATCH RFC 0/6] PSCI-via-EFI to support firmware and kernel sharing EL2 for Apple Silicon

[Sven Peter <sven@kernel.org>]

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