Progress Report: Linux 7.3 – Asahi Linux
Well here we are again. Linux 7.3 is out and it’s been an eventful few months, so
let’s get stuck in to another Asahi Linux progress report!
Upstreaming continues
As always, upstreaming work continues to progress. Aside from the usual patches for
low-level SoC blocks, two major drivers made it on to the list this cycle: macaudio
and avd. Getting macaudio ready for submission has been a challenge. The audio subsystem
on Apple Silicon devices is rather special, and required quite a number of core ALSA
changes to properly support it. Apple also uses special variants of speaker and headset
amplifiers that were already supported upstream, and these drivers also needed some
pretty significant modifications. We have previously discussed a lot of this work at
length, and we are finally in a position where we can submit the main driver for
review. The driver and Devicetree changes represent a hefty chunk of our total patchset,
about 3100 lines.
AVD is a whole different beast. The AVD driver has spent barely 3 months in our downstream
tree and is already on the list. This is our shortest turnaround time yet for a major
SoC component and bodes well for a transition to upstream-first development some time
in the future. This is fantastic news, as the AVD driver and related Devicetree changes
are around 13000 lines of code.
Also making an appearance on the list this cycle are intial Devicetrees not only for M4 Pro
and Max devices but also M5 thanks to Yureka’s tireless efforts. As usual these initial
Devicetrees are barebones and only sufficient to boot the SoC to a TTY, however work
is progressing on further enablement. Watch this space!
We have also begun shifting to an upstream-first approach where practical. Changes
to the TI USB-PD and SPMI drivers required for new devices, as well as initial support
for Thunderbolt, were all developed upstream-first. We are so thrilled to see
our focus on upstreaming starting to pay off!
M3 goes GA
Last time, we announced initial support for M3 series machines via the EXPERT flag on
the Asahi installer. We are pleased to announce that we received almost no issues
from early adopters, so M3 support is now generally available without the EXPERT flag!
We have also made a number of improvements to M3 support, most notably enabling DCP.
On top of performance and battery life improvements, this also allows us to enable
sleep on M3 series devices and make the area around the notch useable on the MacBooks!
Keep an eye out for m1n1 and kernel updates in the coming days.
Crowded House
Last time, we teased support for virtualising SPTM-enabled versions of macOS in m1n1,
which enables reverse engineering on M4 series machines. M5 presents a new challenge,
as the versions of macOS which support it all require the use of Exclaves.
Exclaves are small applications running in an isolated environment controlled by the
Secure Kernel. On M5 series SoCs and above, macOS uses them for sensitive tasks
such as drawing the “camera in use” indicator to the screen. XNU communicates with
the Secure Kernel and its Exclaves via SPTM, using yet another IPC protocol called
Tightbeam. Much as with SPTM, XNU will panic if it cannot find the running Exclaves.
This is all starting to look very similar in concept to Arm’s own TrustZone feature.
While some Exclaves can be bypassed by changing some settings on the command line,
we predict that this will not always be the case. As such, Sven started looking at how we
could fit all of this in to m1n1. First line of investigation, try putting the
Secure Kernel and Exclave userspace in another VM next to SPTM and macOS.
Oh, that worked,
and we’re now up to spawning three VMs in EL1 under m1n1! Maybe we can start
selling m1n1 to companies fleeing VMWare… With that, we can now virtualise
and reverse engineer macOS on both M4 and M5 series machines.
Hello Triangle(s)!
While M3 support is now mostly at feature parity with M1 and M2, the very obvious exception
to this is the GPU. Apple’s GPU team seems to follow a tick-tock model, and the M3’s
GPU was a very significant departure from the models found on M1 and M2 SoCs. We mentioned
quite some time ago that the M3 GPU was being reverse engineered by a new group of
contributors, however not much has been said since.
At XDC this year, Alyssa Millburn,
Anna Maniscalco and TellowKrinkle
gave a talk on their progress
reverse engineering the M3 GPU. Work has progressed far enough for m1n1 to successfully
initialise the GPU and for the team to draw a triangle! Fans of the “Think Different”
sections of these progress reports will find the talk edifying; Apple have once again
made a number of… interesting choices which will require significant engineering
effort to integrate into upstream Mesa. It is well worth a watch if you’re interested
in more detail.
A huge thanks goes out to everyone who has made this work possible. More progress
is on the way, so stay tuned.
Kept you waiting, huh?
All the way back in January of 2024, we made the mistake
of promising Thunderbolt support within the year. It’s a mistake we won’t quickly
repeat. We’ve said almost nothing about Thunderbolt in the two years since, which
begs the question: where is it?
Thunderbolt was originally developed by Apple and Intel, with Intel handling the
design and fabrication of the hardware required. Since Intel made these controllers
available to anyone who wanted them at a (mostly) reasonable price, no one else
bothered to design their own. It is only very recently — largely coinciding with
the transfer of the standard to the USB-IF — that companies like AMD have decided
to roll their own controllers. Apple is of course no exception.
As part of their push for insourcing most silicon IP, Apple made the choice to
design their own Thunderbolt controller before most others. Surprising no one, the
controller is of course a Cortex-M3 running RTKit coupled with a bespoke
Thunderbolt/USB4 router. There is one of these for each Thunderbolt-enabled USB-C port
on all Apple Silicon Macs.
Since Intel supplies every other extant Thunderbolt controller on the market, the
Linux kernel’s Thunderbolt subsystem is effectively designed around them. It makes
a number of assumptions about the hardware topology of the running machine, including
hardware capabilities and access patterns for certain registers and regions of
shared memory. Apple’s controller breaks a lot of these assumptions. Great.
The Thunderbolt controller is also oddly coupled to PMGR. The reset line for each
controller is asserted or deasserted by setting and clearing a set of bits in the
middle of PMGR’s MMIO range. No other hardware block works quite like this,
and it took some time to realise that these seemingly random writes to PMGR were
not just noise.
Luckily for us, Sven was up to the task of dealing with all this nonsense. It just
took slightly longer than expected! While the patchset to enable Thunderbolt was
sent upstream first (another massive win for us!), we have also pulled it into
our downstream kernel and are now shipping it to users!
But there is a catch. Currently, only USB3, XDomain and Thunderbolt Networking are
supported. You can plug in USB devices or connect two Thunderbolt computers together
and make them ping each other, but that’s about it. PCIe and DisplayPort tunnelling — required for
most Thunderbolt docks — are not supported. Yet. Watch this space.
An enormous amount of gratitude is owed to Sven, who has stuck with this thankless
chore for nearly 5 years in between all of his other incredible work.
“The Holy Grail, Doctor Jones”
Playing retail PC games on Asahi Linux is a bit of a pain point, to say the least.
The software stack required to enable this is incredibly complex. We need to translate
x86/amd64 binaries to arm64, and do so fast enough for low-latency gaming. In most
cases, we also need to deal with the Windows API. On top of that, almost all games
bake in an assumed 4 KiB memory page size to enable certain performance optimisation.
Over the past few years, most of these problems have been solved:
- FEX has improved leaps and bounds. The performance and reliability of binary
translation is hardly a consideration in most cases now; - WINE is also fantastic now. Support for ARM64EC is mature and reliable,
meaning that FEX now only has to translate the game binaries rather than
WINE’s entire Windows API implementation; and - muvm allows us to spin up a thin VM with DRM Native Context to present
a 4 KiB memory page size to x86/amd64 applications.
When muvm was first developed, it was with the assumption that DRM Native Context
would enable near-native GPU performance from inside the VM. Unfortunately, this
assumption did not hold. The muvm performance penalty is quite significant for
a number of reasons, about 20% depending on the workload. Engineering around
the limitations inherent to using a VM also introduces issues; muvm cannot use
Wayland, has slow I/O performance, and struggles with certain types of input devices.
This is one area where macOS has us completely licked. While the performance gap
between FEX and Rosetta has narrowed, XNU allows userspace processes to map themselves
at any page granularity, so all Rosetta needs to do is tell XNU to map 4 KiB pages
for its child processes. Linux does not have this flexibility. All pages must be
mapped at the same granularity as the kernel. While we did tease
Windows games working outside of muvm last year, this relied on ugly hacks inside
FEX which have since been removed in the interests of maintainability and translation
correctness. Bummer. Even so, compatibility was hit-and-miss, with a lot of (mostly older)
software still refusing to work. Double bummer.
Android is currently going through a transition from 4 KiB pages to 16 KiB pages for
a variety of reasons. Google Play now requires apps to be built for 16 KiB systems,
and any application updates which do not test successfully on such systems will not
be approved for publication on the Play Store. What about applications which are
no longer updated though? What about sideloaded enterprise slop apps?
Google engineers Kalesh Singh and Frederick Mayle gave a very interesting talk
at Linux Plumbers Conference this year about exactly this. Their solution is simple:
just fix Linux so that userspace can map 4 KiB pages!
Their addition to the Android kernel is called P3S, or Per Process Page Size.
On ARM64 systems, pagetable granularity is controlled by bits set in the Translation Control Registers (TCR).
P3S works by tracking the granularity of each process’s pagetables, and writing
the appropriate bits to the TCR whenever a process with a different pagetable size
is switched to. Because this is a single register write, and because this is
a no-op for “native” page size processes, the performance penalty is effectively
zero!
While this effort is primarily targeted at Android, the patchset mostly rebases
cleanly on top of mainline Linux. What happens if we rebase it on top of our
Asahi tree (and fix some bugs)? As it turns out:
Okay okay, Battlefront is a very simple Direct3D 9.0 game from 22 years ago.
Not exactly an impressive demo, right? Well what about:
Wolfenstein: The New Order is one of the most well optimised native Vulkan
titles ever released, and being 64-bit uses WINE’s ARM64EC pathways to
massively reduce the amount of work FEX has to do. Again, not exactly an
impressive demo if we’re judging based on technical difficulty.
Let’s find something else. Something… worse. Something 32-bit so that
FEX and WINE have to work harder. Something that will exercise DXVK too.
Something that is so comically buggy and poorly optimised that it doesn’t
even work properly on real Windows machines, and relies on community patches
and command line switches to start at all on modern computers:
That’s more like it! But we can do even worse. We can even run…
Bethesda games!
Performance is of course still patchy. Both Battlefront and Wolfenstein
run essentially flawlessly, with the latter hitting 144+ FPS on an M2
Max Mac Studio. GTA IV on the other hand is… not fantastic. Performance
is still massively improved over using muvm, and eliminating the use of
the VM in general should also eliminate a few classes of bugs. Debugging
the GPU driver should also be much easier with this approach.
As always there is a catch, and unfortunately it’s a big one.
The current solution is hard-coded for 16 KiB hosts and 4 KiB processes
on those hosts. This obviously satisfies Google’s commercial requirements, but
adding pagesize-specific kludges to the kernel’s core memory management code
is not appropriate upstream. We are unsure if Google intends to generalise
this approach and upstream it, or if this is going to stay an Android-only patchset.
As such, we do not want to ship this in our downstream tree and have folks
become reliant on it when there is this level of uncertainty.
It also requires userspace integration. P3S works by checking the binary
metadata for its sections’ page alignments. This works for Google’s
use case, as P3S is intended as a fallback mechanism for applications
aligned to 4 KiB pages. Modern arm64 binaries are aligned to 64 KiB however,
as this guarantees compatibility with systems of all native pagesizes. Thus,
a shim is required to force P3S on. The shim triggers P3S, and any
child processes will inherit its 4 KiB pagesize. It is not worth spending
the effort on implementing this until we have some certainty around what
Google intends to do with this patchset.
We have reached out to Google with some questions, and we hope to have more
to say soon.
Mics, but faster
Our custom beamformer for the microphone array found in the MacBooks is written
in Rust. Rust’s scientific computing ecosystem is not as mature as C++’s, which
is a bit of a problem as beamforming requires realtime FFT and very heavy matrix
operations to be done on buffers filled with audio samples. Mature scientific
computing libraries have hand-optimised code, often using intrinsics tied to the
target ISA. We were not doing this however, and relied on the compiler autovectorising
code where it could to achieve our performance targets.
This fell apart when we eliminated the FFT-based analytic transform, replacing it
with an implementation based on infinite impulse response (IIR) filters. This
should be faster, however the compiler was failing to autovectorise the new
implementation. Linkmauve kindly stepped in and
added SIMD-optimised code for both arm64 and amd64. This, coupled with other
performance optimisations courtesy of Frédéric Bour
has resulted in Triforce becoming almost twice as fast, all while using less CPU
time!
Keeping up
Fedora Linux 45 was released on 3 November, and we shipped
Fedora Asahi Remix
on the same day. This is the first time we have been able to get a new version of Fedora
Asahi Remix out on the same day as upstream!
Learning from history
We take great pride in our work, and have always done all of our development in the open.
We communicate with our users, our followers and our financial sponsors as transparently
as is humanly possible. Our finances are in the open, our development branches are in the open,
and we report our progress regularly and candidly in the open. Our IRC channels and Matrix rooms
are safe spaces, open to anyone with even a passing interest in Asahi Linux or hacking on Apple
Silicon.
We do all of this because we firmly believe in Free and Open Source Software, not just as a
means to an end but as the end in and of itself. The modern digital world is only possible
because of the Free Software movement, and it is more important now than it ever has been
that we do all we can to protect the Free Software ecosystem and uphold the ideals upon
which it is built.
It may surprise some to learn that WINE was originally made available under the MIT
licence. The 90s and 2000s were a very different time in the Free Software ecosystem,
and permissively licenced projects were viewed by tech companies as free real estate
to pilfer and exploit. WINE was not immune to this, and many monetised proprietary
forks of WINE were marketed and sold by various bad actors. The WINE development team
grew increasingly concerned that these proprietary forks, while well within their rights
to exist, would eventually cause so much fragmentation in the ecosystem that WINE itself
would become unviable. In 2002, WINE was relicenced under the LGPL to prevent further
proprietary forks from being created, and to encourage direct upstream contribution.
When Asahi Linux was first started, it was with the intent that we develop a Free Software
ecosystem for the Apple Silicon platform. To facilitate and encourage the particiation
of our friends at the BSDs and other Free Software operating systems, we endeavoured to
licence as much of our code as possible under the permissive MIT licence.
Unfortunately, this is no longer viable. The malicious practices of the 90s and 2000s
have reared their ugly heads once again, this time driven in large part by both the
insatiable appetite of frontier AI labs for high-quality training data, and militant animosity
toward the Free Software community.
Some time ago, we were made aware of multiple attempts to exploit our permissive licensing
to hijack our work, with a direct view to replacing the project and aggressively monetising
Linux on Apple Silicon. In some extreme cases, in-development feature code was being
lifted straight out of our personal forks and published without attribution or lazily
rewritten with LLM assistance to obfuscate its origin. The MIT licence explicitly allows
this, and has no carveouts to protect against bad faith actors.
As such, we made the difficult decision to begin the process of transitioning all of
our repositories to the GNU General Public License version 2 or later. Going forward
all Asahi Linux code will be licenced under strong copyleft licences only. Those who
do not learn from history are doomed to repeat it.
Until next time!
As always, we would like to sincerely thank our supporters on OpenCollective
and GitHub Sponsors. It is only through
your generous backing that we are able to dedicate the time and resources to continuing
our work reverse engineering the platform and bringing to it a world-class, polished,
and battle-tested Linux desktop experience. You mean the world to us.
James Calligeros · 2026-11-07
