Asahi Linux plans UEFI-based PSCI conduit to bring proper CPU idle to Apple Silicon

The latest Asahi Linux progress report, published alongside the Linux 7.2 kernel release, explains how the project plans to give Apple Silicon machines proper CPU power management without carrying a vendor-specific driver forever — and how it stopped newer M4 chips from crashing during early boot.

The CPU idle problem

According to the report, one of the biggest remaining obstacles to better battery life on Apple Silicon is not the platform's assortment of power-management hardware blocks (SMC, PMGR and PMP), but the application cores themselves. ARM cores can idle at different depths. The shallowest, a Wait For Interrupt (WFI) instruction, halts execution but keeps the core powered so it can resume work almost instantly. Apple's cores additionally implement a "deep" WFI mode that shuts down more of the core at the cost of losing its state, and Asahi's out-of-tree cpuidle driver exploits this by saving the core's state and then issuing a loop of deep WFI instructions.

The catch is upstreaming. The maintainers of the arm64 architecture code require all hardware supported upstream to use PSCI, the Power State Coordination Interface, a standard mechanism for an operating system to ask firmware to manage core power states. PSCI calls normally travel through an SMC or HVC instruction, which hands execution up to firmware running at a higher Exception Level — EL3. Apple's cores do not implement EL3 at all. Linux runs at EL2 on these machines with no firmware above it to call, so PSCI appeared unusable and the project was left with a downstream-only driver.

One brute-force option, the report notes, would be for the m1n1 first-stage bootloader to load the kernel at EL1 and host PSCI itself at EL2. That would work in theory but would break architectural features such as virtualisation.

A UEFI-based PSCI conduit

The project's answer leans on infrastructure it already ships. On production systems m1n1 loads U-Boot rather than the kernel directly, using its UEFI implementation so that users can boot through GRUB, systemd-boot or any other standard bootloader. UEFI also provides Runtime Services, a way for the operating system to call code that originates in system firmware after boot.

As the report points out, the PSCI specification deliberately defines its API without reference to any specific conduit, listing SMC and HVC only as examples. Contributor Sven has therefore been building a PSCI conduit on top of a UEFI Runtime Service. m1n1 has already been modified to reserve its memory instead of letting the payload reclaim it, and to leave behind a PSCI implementation the kernel can call into even though it runs at the same Exception Level. The kernel patches enabling this are currently on the mailing list as an RFC.

M4 and the locked chicken bits

The report also explains what created recent urgency in this area. The ARM specification mandates that cores in WFI loops preserve all state, but that is not the default behaviour on Apple Silicon. On M1 through M3 SoCs, state retention can be configured per core using so-called chicken bits. Starting with the M4 series, Apple's mBoot bootloader sets those bits itself and then locks down the registers that control them.

The practical consequence is that on an M4, entering WFI makes a core lose its state and crash whatever was running on it — including during early kernel initialisation, before Asahi's cpuidle driver can take over. Contributor Yurkea, who spotted this while doing M4 bring-up work, added a kernel command-line parameter that makes idle loop behaviour configurable, down to a plain no-op loop. Those patches are already in linux-next; once the full driver loads, it saves the state that would be lost before issuing WFI.

Apple's SPTM, explained

Rounding out the report is a walkthrough of Apple's Secure Page Table Monitor. It traces how the earlier Page Protection Layer, which used hardware security features to isolate page-table management from the rest of the XNU kernel, was eventually compromised by attackers and morphed into SPTM. The newer design places that functionality inside Apple's Guarded Execution Framework, a set of Exception Levels running parallel to the standard ARM64 EL1 and EL2, paired with SPRR, a custom page-table permissions system.

Why it matters

If the UEFI conduit lands, Apple Silicon gets a credible path to mainline CPU idle support, which means better battery life for every distribution without Asahi indefinitely maintaining a bespoke driver. The M4 idle patches keep newer Macs bootable at all, and they illustrate how Apple's firmware lockdowns keep narrowing the room third-party operating systems have to manoeuvre. The SPTM section, meanwhile, signals that understanding — and working with or around — Apple's expanding security layers is becoming central to the project's future.