Asahi Linux advances on Apple Silicon: hypervisor runs again on M4, M3 nears official release
The Linux 7.2 progress report details how the team worked around PSCI, SPTM, and the WFI bug that crashed M4, as well as enabling USB 3.0 and Thunderbolt across the entire M3 line.
The Asahi Linux project published its progress report timed to the release of Linux 7.2, and the central message is that running native Linux on Apple Silicon MacBooks is no longer an exercise restricted to the M1 and M2 generations. There are concrete advances on M3, M4, and even initial bringup on M5, but each came at the cost of working around architectural barriers imposed by Apple.
For developers in Brazil who have adopted (or are considering) an M-series Mac as their main machine, the report matters for a practical reason: it defines how much of the hardware actually works under Linux today and what still depends on ongoing reverse engineering.
The power management problem: PSCI without EL3
The biggest obstacle to improving battery life wasn't in the power management blocks (SMC, PMGR, PMP), but in the CPU cores themselves. The upstream arm64 kernel requires all CPU power management to go through PSCI (Power State Coordination Interface), which prevents Asahi from upstreaming its Apple-specific cpuidle driver to the official kernel.
The detail that blocks everything: PSCI expects to dispatch calls to firmware running in EL3 via SMC or HVC instructions. But, as the team explains, Apple's cores simply don't implement EL3. With the kernel already in EL2 and nothing in EL3 to talk to, there's no way to use PSCI in the standard way.
Sven's proposed solution is creative: use m1n1 (the project's bootloader, which behaves almost like firmware) as a new PSCI conduit based on UEFI Runtime Services. The reading is that the Arm specification defines the API without tying it to a specific conduit, listing SMC and HVC only as examples. m1n1 reserves its memory region like other firmware blobs and leaves an active PSCI implementation that the kernel can call back into, even while running in the same Exception Level. The patches are already on the kernel mailing list as an RFC.
The WFI bug that crashed the M4
The trigger for this work was a problem on the M4. The Arm specification mandates that cores in a WFI (Wait For Interrupt) loop preserve all state, but that isn't the default behavior on Apple Silicon. On the M1 through M3 SoCs, it was possible to configure per-core state retention via chicken bits.
Starting with the M4, Apple began setting these bits in mBoot and locking the registers that control them. The result: on M4, calling WFI makes the core lose its state and crash whatever was running on it. Yureka identified this during bringup and added a kernel command-line parameter to configure the idle loop behavior (including a basic no-op loop), avoiding the crash during initial boot before the cpuidle driver takes over. These patches are already in linux-next.
SPTM: the hypervisor works again on M4
The thorniest obstacle is the Secure Page Table Monitor (SPTM), an evolution of Apple's Page Protection Layer. SPTM isolates page table management within the Guarded Execution Framework (GXF), a set of Exception Levels parallel to standard ARM64, with its own permission system called SPRR.
On modern devices, mBoot loads SPTM in GL2 before XNU; if XNU can't make contact with SPTM, it panics right at init. Since SPTM became mandatory for XNU on M4 and later, the m1n1 hypervisor, an essential tool for reverse-engineering new hardware, became completely inoperative on those machines.
The solution came from Sven's earlier work reverse-engineering SPRR and GXF: he taught the hypervisor to emulate both. This allows loading Apple's own SPTM blob the way XNU expects, performing a small bit of surgery on the XNU binary, and going back to monitoring MMIO accesses as on M1 through M3. Tracing became slower on these machines, but, according to the report, not to the point of being unworkable. This is what keeps alive the ability to support new hardware.
"You have to appreciate the effort Apple puts into security, goes some way to understanding why they won't endorse/support installing an alternative operating system."
>
M3 nears official release
For those with an M3 Mac, this is the most concrete section. The report lists support that now works:
| Component | Status on M3 | |---|---| | Built-in webcam | Functional on all M3 with webcam (including M3 Max) | | Built-in microphones | Functional on all equipped models | | USB 3.0 and Thunderbolt | Functional across the entire M3 line | | GPU/display ABI (DCP) | Near parity with the ABI used on M1/M2 |
The USB 3.0 and Thunderbolt point deserves technical highlighting: starting with the M3 Pro/Max, Apple swapped the TI CD3217 (ACE2) USB port controller, which sat on the I2C bus, for the ACE3, which uses the SPMI bus. The combined effort of mildsunrise and chaos_princess discovered that ACE3 has practically the same register set as the CD3217, just wrapped in an SPMI interface. In the Hacker News thread, JLO64, an M3 Pro owner, sums up the feeling of those who depend on this work:
"When I got my M3 Pro MBP, I got it with the intention of eventually installing Linux on it. In hindsight I seriously underestimated the amount of effort needed for even partial Linux compatibility, which makes me all the more grateful for the work Asahi contributors have put in!"
>
With these milestones, the team announced being "almost ready" to cut an official release for M3, with more details in the coming weeks.
M4 and M5: NVMe works, but it's not yet for daily use
Beyond WFI, M4 and M5 suffered from a change breaking the NVMe controller firmware bundled in macOS 15.x. Yureka and Sven implemented the changes in m1n1 and Linux, and now NVMe works on M4 and M5. PCIe already enumerates devices on the bus, and a bug that crashed Linux right after boot with more than one core active has been fixed. Even so, the report is clear: little else works on these SoCs, and they won't be enabled in the Asahi Installer for now.
Video decoding runs into the desktop ecosystem
The Apple Video Decoder (AVD) accelerates H.264, H.265, and VP9 on M1/M2, plus AV1 on M3 and later, and support for AVC, HEVC, and VP9 already works mostly reliably. The obstacle here isn't Apple, but Linux: the AVD is a stateless decoder, which fits the V4L2 Stateless API, but desktop software (browsers, FFmpeg) has historically focused on VA-API, NVDEC, and VDPAU.
The bridge is a VA-API to V4L2 Stateless translation layer, originally from Bootlin and abandoned, revived in a fork by megi and adapted by sofus. With it installed and an environment variable set, software with VA-API support already uses the AVD. The caveat: it still doesn't ship by default on Fedora Asahi Remix and doesn't work with Firefox's decoding sandbox. In the thread, megous himself warns about the limits of this approach:
"Yeah, you'll find out that va-api is not a good match for v4l2-requests. It does not pass decoded bitstream to the drivers as is, but pre-computes some things for some codecs, while v4l2-requests mostly expects original information parsed from the bitstream."
>
What remains open
For the Brazilian developer evaluating a Mac as a Linux workstation, the honest read is: M1 and M2 remain the most mature, M3 is moving toward official support, and M4/M5 are still in bringup. Battery life, historically Linux's Achilles' heel on laptops, depends on the progress of PSCI via UEFI Runtime Services, still at the RFC stage. None of this is finalized, but the report shows that the main architectural blockers have a solution path underway.
Translated from the Brazilian Portuguese original · Read the original
Perplexity swaps DynamoDB for in-house database and cuts latency by 5x
The company behind the AI-powered search engine migrated its serving layer to CobbleDB, an internal database written in Rust, and cut batch read latency by up to 5x while saving at least 20% on storage.
