What did Asahi Linux's Linux 7.3 report announce?
Asahi Linux published its Linux 7.3 progress report on 7 November 2026. The project ports Linux to Apple Silicon Macs and reports roughly once per kernel cycle. This edition, written by James Calligeros, covers three separate changes: M3 support reaching general availability, partial Thunderbolt support, and a licence switch.
The title refers to the kernel cycle rather than to a separately versioned Asahi release. The project ships its work through the kernel, through m1n1 and through Fedora Asahi Remix.
The licence change is the most consequential item. Every Asahi repository will move from the permissive MIT licence to the GNU General Public License version 2 or later. The project says it acted after repeated attempts to take its code, replace the project and sell Linux on Apple Silicon.
For people who own an M3 MacBook Air, MacBook Pro or iMac, the practical news is narrower but immediate. The report declares M3 support generally available, so these machines are treated as supported hardware rather than an experiment.
None of this is endorsed by Apple. Asahi is an independent reverse-engineering effort, and Apple does not ship or support it. The changes apply to the downstream Asahi kernel and Fedora Asahi Remix, not to the mainline kernel that other distributions package.
Asahi began with the 2020 M1 Mac mini, MacBook Air and MacBook Pro. Its stated goal is a Linux desktop polished enough for daily use on an undocumented platform. Apple itself permits booting custom kernels on these Macs, so Asahi is not a jailbreak.
The project publishes its finances and development branches in the open, which makes a licensing reversal unusually visible. Readers can follow the reasoning rather than infer it from a changelog.
The report matters beyond one distribution. Asahi's drivers are upstreamed into Linux, its installer is the reference path onto Macs, and its licensing choice shapes what other projects can legally reuse. It also lands during a wider argument about AI training data and open-source licences.
For Mac owners, the trade-off is unchanged. Asahi gives Apple Silicon machines a supported Linux path, but graphics, docking and some media features still fall short of macOS.
Why is M3 support now generally available?
Asahi opened M3 machines to testers in September 2026. The project dropped the installer's expert-mode requirement on 15 September, but still described the support as fresh. Sleep and HDMI output were among the known limitations.
Both traced back to DCP, the display coprocessor. The new report says DCP is now enabled on M3. That improves performance and battery life, allows sleep, and makes the area around the MacBook notch usable.
Without DCP, the kernel had fallen back to a firmware-provided framebuffer, which limited sleep. The missing DCP also disabled the HDMI port on equipped MacBooks.
The report now declares M3 support generally available. It credits early adopters, who reported almost no issues after the initial rollout.
Much of the hardware already worked in September. The project listed the webcam, internal microphones, USB 3 at 10 Gb/s, hardware video decoding including AV1, Wi-Fi and Bluetooth.
Fedora Asahi Remix 45 arrived on 3 November, the same day as Fedora Linux 45, with KDE Plasma 6.8 and GNOME 51. Its announcement said M3 graphics drivers were not included and would arrive later through a Mesa update.
The remix is installed by running a script rather than writing an ISO image. It ships KDE, GNOME, Server and Minimal variants, and Fedora's announcement says Asahi upstream now officially supports the new M3 systems.
Coverage is uneven across the M3 family. MacBooks and iMacs with M3, M3 Pro or M3 Max are supported. The Mac Studio with M3 Ultra is not, and the project's feature table still marks most of it as not started.
General availability does not mean mainline support. The device trees for M4 Pro, M4 Max and M5 are only enough to reach a text console, and the M3 graphics driver is still missing.
How much Thunderbolt support does Asahi Linux have now?
Thunderbolt support was promised in 2024 and then went quiet for two years. The patches are now on the kernel mailing list and shipping in the Asahi kernel. The support is partial, and the gap is the part most people care about.
In practice, a user can plug in a USB device or link two Thunderbolt machines and ping between them. A docking station with Ethernet, extra displays or storage will not work as expected.
Thunderbolt matters for laptop users because one cable normally carries displays, storage and networking. Without PCIe tunnelling, an external NVMe enclosure or a dock's network port stays invisible to the operating system.
- •Supported: USB 3 devices, XDomain connections and Thunderbolt Networking between two computers.
- •Not supported yet: PCIe tunnelling and DisplayPort tunnelling, which most Thunderbolt docks rely on.
Why are Thunderbolt docks still unsupported?
The delay is explained by Apple's hardware. Apple builds its own Thunderbolt controller, one per Thunderbolt-capable USB-C port. It pairs a Cortex-M3 running RTKit with a bespoke Thunderbolt and USB4 router.
Linux's Thunderbolt subsystem was designed around Intel controllers and their assumptions about topology and shared memory. Apple's controller breaks several of them, which meant rethinking parts of the driver.
The controller also has an unusual reset arrangement. Its reset line is controlled by bits inside PMGR's memory-mapped register range, which took the team time to identify. Sven, a contributor, carried the work for nearly five years.
Sven Peter, credited on the project's About page with earlier work on Apple's address translation hardware, has been the constant on DisplayPort and Thunderbolt. The patches were developed upstream-first, which the project counts as a win.
Even so, the patches have only reached the mailing list. Until PCIe tunnelling lands, Thunderbolt stays a connectivity feature rather than a way to replace a desktop setup.
Can Apple Silicon Macs run Windows games without a virtual machine?
The report's most striking demonstration is Windows games running outside muvm, the lightweight virtual machine Asahi uses for x86 software.
Three pieces normally make this work. FEX translates x86 and amd64 binaries to Arm. WINE supplies the Windows API, now with mature ARM64EC support. muvm presents a 4 KiB memory page size, because many games assume it.
The 4 KiB assumption is baked into how many games allocate memory. Linux normally forces every process to use the kernel's page size, while macOS lets Rosetta map smaller pages for its child processes.
muvm works, but it is costly. The project measured a penalty of about 20% depending on workload. The VM cannot use Wayland, has slow input and output, and struggles with some input devices.
The fix comes from Android. Google engineers Kalesh Singh and Frederick Mayle presented P3S, or Per Process Page Size, at Linux Plumbers Conference. It tracks each process's page-table granularity and rewrites control-register bits on context switch. Native processes pay effectively nothing.
Android is moving from 4 KiB to 16 KiB pages, and Google Play now requires app updates to pass on 16 KiB systems. P3S exists so older apps that still assume 4 KiB pages keep running.
Rebased onto the Asahi tree, P3S let the team run games outside the VM. Star Wars Battlefront (2004) and Wolfenstein: The New Order ran essentially flawlessly. Wolfenstein passed 144 frames per second on an M2 Max Mac Studio. GTA IV ran too, though performance was not good.
The catch is large. The current implementation is hard-coded for 16 KiB hosts and 4 KiB processes. It also needs a shim, because modern arm64 binaries are aligned to 64 KiB.
Eliminating the virtual machine also removes several classes of bugs, according to the report. It should make debugging the graphics driver easier too.
Asahi will not ship this while Google's upstream plans are unclear. The project says it has asked Google for answers and expects to say more later.
Why is Asahi Linux moving from MIT to GPLv2?
Asahi chose MIT at the start so that BSD projects and other free operating systems could reuse its work. The project now says that is no longer viable.
The report describes this as the start of a transition rather than a single switch. Going forward, all Asahi code will use strong copyleft licences only.
The report describes attempts to exploit the permissive licence. It says in-development code was taken from personal forks and published without attribution, or "lazily rewritten with LLM assistance to obfuscate its origin". It also points to frontier AI labs' demand for training data.
The project describes MIT as offering no carveouts against bad-faith use. It calls the decision to leave it difficult, after years of permissive licensing aimed at helping neighbouring projects.
The report does not name any person or company. The Register reported in September that Gravity Linux, a distribution forked from Asahi, cited "differences in policy, namely regarding LLM use" as its reason for leaving.
That fork's lead, Cody Ho, previously worked at Apple and OpenAI. With co-developer Niklas Sheth he built an M4 GPU driver in about a month, largely through unattended LLM loops. The project's alpha booted an accelerated desktop on an M4 Mac mini.
Asahi's own policy forbids that method for contributions. It states that the project will "broadly forbid the use of generative AI tooling for material contributions", because LLMs can taint clean-room reverse engineering.
There is precedent. WINE was MIT-licensed until 2002, when it moved to the LGPL to stop proprietary forks. The report ends that section with a familiar warning: "Those who do not learn from history are doomed to repeat it."
The project's About page still describes a plan to dual-licence code under the upstream licence and a permissive one. The new report supersedes that promise, so the documentation is now behind the decision.
The Register's account adds nuance. It says Gravity's code still needs extensive testing, human review and refactoring before upstreaming. Its kernel driver may also have to wait for Asahi's M1 and M2 driver to land first.
The switch does not ban commercial use. GPLv2 still allows selling software and shipping it inside products. Anyone distributing modified binaries must provide the source under the same terms. For the BSDs, permissive reuse of Asahi's MIT code now ends.
For people who simply install Fedora Asahi Remix, little changes day to day. The licence governs redistribution and modification, not ordinary use.
What still does not work, and what should you watch next?
Graphics remains the biggest gap on M3. Apple's M3 GPU differs substantially from the M1 and M2 designs. The reverse-engineering team can now initialise it in m1n1 and draw a triangle, which is early progress rather than a usable driver.
Alyssa Millburn, Anna Maniscalco and TellowKrinkle presented that work at XDC. The report says integrating it into upstream Mesa will need significant engineering.
Other gaps are documented in the project's feature table. Video encoding and the ProRes codec are listed as not started on M3 hardware. M3 Ultra support is not started either.
Newer chips are moving more slowly. The report says initial device trees for M4 Pro, M4 Max and M5 were submitted upstream. Those trees are barebones and only sufficient to boot to a text console.
Yureka is credited with that device tree work. The project has also begun submitting some changes upstream-first, including TI USB-PD, SPMI and the initial Thunderbolt patches.
Reverse engineering macOS on those machines needed another step. M5 Macs rely on Exclaves, small applications controlled by the Secure Kernel, and on a protocol called Tightbeam. The team now runs three virtual machines at EL1 under m1n1, the project's hypervisor, to handle it.
XNU, the macOS kernel, panics if it cannot find the running Exclaves, so the team cannot skip them. The report compares the design to Arm's TrustZone feature.
Upstream work continues in parallel. The macaudio driver is about 3,100 lines, and the AVD driver is about 13,000 lines after barely three months downstream. The project calls that its fastest turnaround for a major component.
Smaller gains matter too. SIMD work from Linkmauve and other optimisations from Frédéric Bour made the Triforce microphone beamformer almost twice as fast.
The Register noted in September that Apple had announced the M6 a month earlier. That gap explains why Asahi is still finishing M3 while newer chips ship.
Anyone considering an install should check the feature table for the exact model first. Support differs by chip and by machine, and the table is the project's current list.
The next signals to watch are an M3 GPU driver in Mesa, Google's decision on upstreaming P3S, and PCIe tunnelling for Thunderbolt docks. The licence change will also be tested, because copyleft only matters when someone redistributes.