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

[Mark Rutland]

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.

Mark.