Asahi Linux's 7.3 progress report reads less like a changelog and more like a strategic inflection point. The project is transitioning from pure reverse engineering toward upstream-first kernel development — submitting patches to mainline Linux before pulling them downstream. Two major drivers, macaudio (~3,100 lines) and AVD (~13,000 lines), are now on the upstream submission list. AVD's turnaround from downstream to upstream in barely three months is the fastest for any major SoC component in the project's history. M3 support has graduated from EXPERT-flag early access to general availability, with DCP enablement bringing sleep support and notch-area usability to MacBooks. More striking is the M5 reverse engineering story: Apple's newest chips require macOS to communicate with 'Exclaves' — isolated secure-kernel applications — via a protocol called Tightbeam through SPTM. The Asahi team's solution was to spin up three simultaneous VMs under m1n1, nesting the Secure Kernel and Exclave userspace alongside SPTM and macOS. It works. The quip about selling m1n1 to companies fleeing VMware is only half a joke. Thunderbolt is the headline delivery. Apple designed its own Thunderbolt controller — a Cortex-M3 running RTKit with a bespoke USB4 router — breaking most assumptions in the Linux Thunderbolt subsystem, which was built around Intel's controllers. The reset line is coupled to PMGR in a way no other hardware block uses. Sven's patchset was developed upstream-first and is now shipping to users, though only USB3, XDomain, and Thunderbolt Networking work today. PCIe and DisplayPort tunnelling — the stuff that makes docks function — are not yet supported. The M3 GPU remains the biggest gap. Apple's tick-tock GPU model means the M3 architecture diverged significantly from M1/M2. A new group of contributors — Alyssa Millburn, Anna Maniscalco, and TellowKrinkle — presented their reverse engineering progress at XDC, having reached the 'hello triangle' milestone. Integrating Apple's architectural choices into upstream Mesa will require significant engineering effort. This is the long pole in the tent for M3 feature parity. The most structurally honest section of the report concerns gaming. The software stack for running x86 PC games on ARM64 Linux requires binary translation (FEX), Windows API translation (WINE with ARM64EC), and a thin VM (muvm) to present 4 KiB memory pages. FEX and WINE have matured impressively, but muvm imposes a roughly 20% performance penalty, breaks Wayland support, degrades I/O, and struggles with certain input devices. macOS doesn't have this problem because XNU lets userspace map pages at arbitrary granularity. Linux requires all pages to match the kernel's page size. The ugly FEX hacks that bypassed muvm were removed for correctness. This is a kernel-level architectural constraint, not a fixable bug. Android's ongoing migration from 4 KiB to 16 KiB pages — with Google Play now requiring 16 KiB compatibility — suggests the ecosystem is moving away from 4 KiB assumptions. Whether this eventually helps or hurts Asahi's gaming story depends on whether game developers stop hardcoding 4 KiB page sizes, a process that could take years. The Asahi team is betting on ecosystem evolution rather than kernel hacks, which is the right long-term call but offers no short-term relief. What emerges from this report is a project that has matured from scrappy reverse engineering into a serious upstream Linux development effort. The upstream-first pivot for Thunderbolt, USB-PD, and SPMI drivers represents a fundamental change in development philosophy. The remaining gaps — GPU, Thunderbolt tunnelling, gaming performance — are all hard engineering problems, not strategic dead ends. The constraint that matters most is the one nobody can fix with a patch: Linux's page-size inflexibility.
