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

[Ard Biesheuvel]

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.