Beim Ausführen von Windows-Spielen auf Apple-Silicon-Hardware liegt der maßgebliche Flaschenhals längst nicht mehr bei der Befehlsübersetzung. Das eigentliche technische Hindernis resultiert aus der globalen Festlegung der Speicherseitengröße im Linux-Kernel. Am 7. November 2026 veröffentlichte das Asahi-Linux-Team seinen Fortschrittsbericht zu Linux 7.3. Dank des P3S-Patches aus dem Android-Ökosystem gelang es den Entwicklern, x86-Spieletitel vollständig ohne zwischengeschaltete virtuelle Maschine auszuführen.
Drei Schichten Overhead kosten 20 % Leistung: Der Flaschenhals der 4K-Pages
Um PC-Spiele unter Asahi Linux auszuführen, mussten bisher drei voneinander getrennte Laufzeitschichten gestapelt werden. Auf der untersten Ebene übersetzt FEX dynamisch x86-Befehle in arm64-Instruktionen. In der Mitte fängt WINE die Windows-API-Aufrufe ab. An der Spitze startet muvm eine leichtgewichtige Mikro-VM, um älteren Programmen eine Speicherseitengröße von 4 KiB vorzuspiegeln.
Ursprünglich sollte muvm über DRM Native Context einen nahezu nativen Grafikdurchsatz sicherstellen. Praktische Messungen widerlegten diese Erwartung: Die Virtualisierungsschicht forderte einen Leistungstribut von rund 20 Prozent. Durch die Überlagerung von Binärübersetzung und VM-Verlusten ging ein Fünftel der nativen Grafikleistung der Hardware verloren.
Neben Einbußen bei der Bildrate zog die VM-Architektur etliche Folgeprobleme nach sich. muvm ließ sich nur unzureichend an das Wayland-Protokoll anbinden; Fensterverwaltung und Zwischenablage reagierten häufig nicht mehr. Der I/O-Durchsatz des virtualisierten Dateisystems brach spürbar ein, und auch die zuverlässige Eingabeanbindung externer Gamepads gestaltete sich schwierig.
macOS handhabt Pages flexibel, Linux bleibt systemweit festgelegt
Dass ältere Spieletitel strikt auf 4-KiB-Speicherseiten angewiesen sind, ist eine historische Altlast der x86-Architektur. Frühere Windows-Spiele und 32-Bit-Programme setzten stets eine feste Seitengröße von 4 KiB voraus. Viele Speicher-Allokatoren schrieben den Wert von 4096 Byte fest in die Binärlogik ein. Wird ein solches Programm auf einem System mit größeren Speicherseiten gestartet, stürzt es wegen unzulässiger Speicherzugriffe unweigerlich ab.
Apple-Silicon-Chips arbeiten standardmäßig mit 16-KiB-Seiten. macOS begegnet dieser Anforderung durch die flexible Architektur des XNU-Kernels, der es Prozessen im Userspace gestattet, eigene Mapping-Granularitäten festzulegen. Startet Rosetta ein x86-Spiel, weist der Kernel diesem Kindprozess exklusiv einen 4-KiB-Adressraum zu – das Gesamtsystem muss keinerlei Kompromisse eingehen.
Der Linux-Kernel stieß hierbei an fundamentale architektonische Grenzen. Das traditionelle Linux verlangt zwingend, dass alle Prozesse im System dieselbe einheitliche Speicherseitengröße teilen. Zwar unternahm das Asahi-Team im vergangenen Jahr Versuche, 4-KiB-Umgebungen direkt in FEX zu simulieren; aus Gründen der Code-Wartbarkeit und Übersetzungskorrektheit wurden diese Hilfspatches jedoch wieder entfernt.
Ein ARM64-Register genügt: Seitengrößen pro Prozess
Der entscheidende Impuls zur Überwindung des Stillstands kam aus dem Mobilsektor. Android befindet sich inmitten einer Umstellung von 4-KiB- auf 16-KiB-Speicherseiten. Da Google Play für neue Apps inzwischen die 16-KiB-Kompatibilität vorschreibt, drohten zahlreiche ungepflegte Altanwendungen beim Start abzustürzen. Googles Ingenieure mussten folglich einen universellen Weg finden, um 4-KiB-Prozesse auf einem 16-KiB-Kernel auszuführen.
Auf der Linux Plumbers Conference stellten Google-Ingenieure den P3S-Mechanismus vor – kurz für Per Process Page Size. In der ARM64-Architektur wird die Granularität der Seitentabellen über Steuerbits im Translation Control Register (TCR_EL1) bestimmt. Die Hardware selbst unterstützt den dynamischen Wechsel der Übersetzungseinheiten von Haus aus.
Der P3S-Patch registriert im Kernel die jeweils benötigte Seitentabellengröße jedes Prozesses. Führt der Scheduler einen Kontextwechsel durch, schreibt das System die entsprechende Konfiguration direkt in das TCR-Register. Ein einzelner Registerzugriff entspricht für native Prozesse praktisch einem Nullbetrieb (no-op) und verursacht nahezu null CPU-Overhead. Dieser hardwarenahe Umschaltmechanismus entzieht der aufwendigen VM-Infrastruktur jede Existenzberechtigung.
Vier Klassiker ohne VM: Bildraten von über 144 FPS
Das Asahi-Team portierte das P3S-Patchset auf seinen eigenen Branch von Linux 7.3. Mehrere ikonische PC-Klassiker wurden umgehend direkt auf dem Host-System getestet. Das 2004 erschienene Star Wars: Battlefront startete über WineD3D ohne Zwischenfälle. Das Rendering lief fehlerfrei, ohne die gefürchteten Speicheradressierungsabstürze früherer Tage.
Abb.: Star Wars: Battlefront (2004) läuft außerhalb von muvm über WineD3D. Quelle: Offizieller Asahi-Linux-Fortschrittsbericht
Das grafisch anspruchsvollere Wolfenstein: The New Order verdeutlichte den Leistungszuwachs noch drastischer. Auf einem Mac Studio mit M2 Max knackte das Spiel mühelos die Marke von 144 FPS. Der Verzicht auf die virtuelle Maschine holte 20 % Grafikleistung zurück und bewies, dass die ARM64-Übersetzungsschicht auch anspruchsvolles High-Refresh-Gaming stemmen kann.
Abb.: Wolfenstein: The New Order (2014) außerhalb von muvm mit über 144 FPS auf einem M2 Max Mac Studio. Quelle: Offizieller Asahi-Linux-Fortschrittsbericht
Ebenfalls getestet wurde das für seine notorisch heikle Kompatibilität bekannte Grand Theft Auto IV aus dem Jahr 2008. Der 32-Bit-Titel benötigt selbst auf physischen Windows-Rechnern oft Community-Patches, um überhaupt zu starten. Mittels DXVK zur Vulkan-Übersetzung zeigte das Spiel außerhalb von muvm eine beachtliche Steigerung der Bildwiederholrate. Auch das traditionsgemäß zickige Fallout: New Vegas lief ohne die bekannten VM-Ruckler.
Abb.: Grand Theft Auto IV (2008) außerhalb von muvm via DXVK. Ein 32-Bit-Alttitel, bewusst gewählt als härtester Härtetest. Quelle: Offizieller Asahi-Linux-Fortschrittsbericht
Der Wegfall der VM sorgte nicht nur für flüssige Bildraten, sondern vereinfachte auch die Treiberentwicklung enorm. Zuvor erforderte das Eingrenzen von Darstellungsfehlern die Fehlersuche über zwei getrennte Treiber-Stacks (Host und Guest). Da Grafikbefehle nun direkt an den nativen Treiber durchgereicht werden, verkürzten sich die Analysezyklen bei GPU-Fehlern um ein Vielfaches.
Kernel-Sonderlösungen: Unsicherheiten beim Upstream-Merge
Trotz der beachtlichen Ergebnisse befindet sich P3S noch in einem experimentellen Entwicklungsstadium. Das aktuelle Patchset ist fest auf die Kombination aus einem 16-KiB-Host und 4-KiB-Prozessen ausgelegt. Dies erfüllt zwar die kommerziellen Zwecke von Google, lässt jedoch eine saubere architektonische Abstraktion vermissen. Spezifische Sonderlösungen in den Kern der Linux-Speicherverwaltung einzubringen, stößt bei Upstream-Kernel-Maintainern regelmäßig auf erhebliche Vorbehalte.
Auch auf Userspace-Ebene bleiben Hürden bestehen. P3S liest Metadaten im Binär-Header aus, um die Seitenausrichtung zu bestimmen. Moderne arm64-Binärdateien sind zugunsten breiter Kompatibilität standardmäßig an 64-KiB-Grenzen ausgerichtet. Derzeit ist daher ein spezielles Shim-Tool erforderlich, um P3S zu erzwingen, damit Kindprozesse die 4-KiB-Umgebung korrekt erben.
Angesichts dieser Unwägbarkeiten agiert das Asahi-Team zurückhaltend. Solange Googles Pläne für eine offizielle Upstream-Integration nicht feststehen, wird die Funktion in den Asahi-Downstream-Distributionen nicht standardmäßig aktiviert. Das Team will abwarten, bis die Kernmechanismen im offiziellen Linux-Kernel akzeptiert sind.
Der Bericht hielt zudem weitere Hardware-Fortschritte fest. Die M3-Chipfamilie verließ den experimentellen Status und wird nun regulär unterstützt; die DCP-Display-Engine beherrscht inzwischen Sleep/Wake-Zyklen sowie die Aussparung des Notch-Bereichs bei MacBooks. Erste Upstream-Patches für Thunderbolt brachten USB3- und Netzwerkunterstützung, und Fedora Asahi Remix erschien erstmals am selben Tag wie die Upstream-Version von Fedora Linux 45.
Die Portierung von Windows-Spielen auf ARM64 wandelt sich von reiner Userspace-Emulation zu tiefgreifenden Eingriffen in die Kernel-Architektur. FEX hat gezeigt, dass Binärübersetzung hocheffizient arbeitet; der verbliebene Engpass lag im Fundament der Betriebssystem-Speicherverwaltung. P3S ersetzt eine schwerfällige virtuelle Maschine durch einen minimalen Registerzugriff und spart 20 % Leistungsverlust ein. Fällt diese Hürde im Kernel, verliert das plattformübergreifende Gaming endlich seinen schwersten Ballast.
Weiterführende Links:
- Offizieller Asahi-Linux-Fortschrittsbericht (James Calligeros)
- Vortrag auf der Linux Plumbers Conference 2026 (Kalesh Singh, Frederick Mayle)
