When running Windows games on Apple Silicon hardware, the primary performance bottleneck is no longer instruction translation. The real technical barrier stems from the Linux kernel’s global lock on memory page size. On November 7, 2026, the Asahi Linux team published its Linux 7.3 progress report. By borrowing Android’s P3S patchset, developers have successfully freed x86 gaming workloads from the constraints of virtual machines.
Three Layers of Overhead Consume 20% Performance: The 4K Page Bottleneck
Historically, playing retail PC games on Asahi Linux required stacking three distinct runtime layers. At the bottom, FEX handles dynamic translation from x86 instructions to arm64. In the middle, WINE intercepts and implements Windows API calls. At the top, muvm spins up a lightweight micro-VM to present a 4 KiB memory page size to legacy applications.
The original intent behind muvm was to leverage DRM Native Context to deliver near-native graphical throughput. Real-world engineering benchmarks shattered that expectation, revealing a performance penalty of around 20% due to virtualization overhead. Layering binary translation on top of a virtual machine ends up swallowing a fifth of the hardware’s native graphical horsepower.
Beyond lost framerates, the VM architecture introduced a cascade of peripheral headaches. muvm struggled to integrate cleanly with the Wayland desktop protocol, frequently causing window management and clipboard synchronization to hang. Virtualized filesystem I/O suffered noticeable throughput drops, and mapping gamepads and other external peripherals reliably proved difficult.
macOS Relies on System Flexibility; Linux Remains Locked to Unified Pages
Legacy games depend on 4 KiB memory pages largely due to the architectural heritage of x86. Older Windows titles and 32-bit software assumed that system page sizes were universally fixed at 4 KiB. Many custom memory allocators hardcoded 4096-byte boundaries directly into their binary logic. When executed on an operating system with larger pages, these binaries quickly crash due to out-of-bounds memory accesses.
Apple Silicon hardware operates with 16 KiB pages by default. macOS accommodates this through the flexible virtual memory architecture of its XNU kernel, allowing userspace processes to define custom mapping granularities. When Rosetta launches an x86 game, the kernel allocates a dedicated 4 KiB address space specifically for that child process, requiring zero system-wide compromises.
The Linux kernel hits a fundamental architectural divide here. Traditional Linux mandates that every process across the entire system share a uniform memory page size. Last year, the Asahi team experimented with emulating a 4 KiB environment within FEX itself. However, to preserve code maintainability and translation correctness, those temporary hacks were ultimately removed.
Flipping an ARM64 Register: Per-Process Page Sizes
The impetus to break this deadlock arrived from the mobile ecosystem. Android is actively navigating an ecosystem-wide migration from 4 KiB to 16 KiB pages. Google Play now requires new application submissions to support 16 KiB architectures, threatening unmaintained legacy software with immediate startup crashes. Google engineers were compelled to engineer a general mechanism capable of hosting 4 KiB processes on a 16 KiB kernel.
At the Linux Plumbers Conference, Google engineers introduced the P3S mechanism, short for Per Process Page Size. On ARM64 systems, pagetable granularity is governed by specific bitflags configured in the Translation Control Register (TCR_EL1). The hardware architecture inherently supports dynamically altering page translation granularities on the fly.
The P3S patchset tracks the required pagetable granularity for each running process directly in kernel space. Whenever the scheduler executes a context switch, the system writes the corresponding configuration bits into the TCR register. A single register write is practically a no-op for native processes, introducing near-zero CPU overhead. This hardware-level switching directly eliminates the need to maintain an entire virtual machine layer.
Four Legacy Titles Shed the VM: Hitting 144+ FPS
The Asahi team rebased the P3S patchset onto their own Linux 7.3 kernel branch. Several iconic PC classics were immediately tested running bare-metal outside of a VM. Released back in 2004, Star Wars: Battlefront booted up smoothly under WineD3D. Graphics rendered cleanly without any of the memory addressing crashes seen in previous attempts.
Fig: Star Wars: Battlefront (2004) running outside muvm via WineD3D. Source: Asahi Linux official progress report
The more demanding Wolfenstein: The New Order delivered an even more striking performance demonstration. On an M2 Max Mac Studio, the game effortlessly surpassed 144 FPS. Ditching the virtual machine immediately recovered 20% in graphics throughput, proving that the ARM64 translation pipeline can comfortably drive high-refresh gaming displays.
Fig: Wolfenstein: The New Order (2014) running outside muvm, exceeding 144+ FPS on an M2 Max Mac Studio. Source: Asahi Linux official progress report
The team also tested 2008’s Grand Theft Auto IV, a title infamous for its fragile compatibility. Even on genuine Windows machines, this 32-bit port frequently requires community patches and custom launch arguments to run at all. With DXVK translating DirectX calls to Vulkan outside muvm, the title saw a massive leap in fluid gameplay. The notoriously finicky Fallout: New Vegas likewise ran cleanly without virtual machine stutter.
Fig: Grand Theft Auto IV (2008) running outside muvm via DXVK. A 32-bit legacy title chosen deliberately as a worst-case compatibility scenario. Source: Asahi Linux official progress report
Eliminating the virtual machine did more than unlock fluid framerates; it substantially simplified driver debugging workflows. Tracking down rendering artifacts previously meant navigating two separate driver stacks across host and guest environments. With graphical commands now routing directly into native drivers, GPU triage and troubleshooting cycles have been cut down dramatically.
Hardcoded Kernel Kludges: Upstream Acceptance Remains Uncertain
Despite its impressive results, P3S remains in an early experimental engineering stage. The current patchset hardcodes a configuration specifically matching 16 KiB hosts and 4 KiB child processes. While this directly satisfies Google’s commercial requirements for Android, it lacks generalized architectural abstraction. Injecting pagesize-specific kludges into the core memory management subsystem of Linux is bound to trigger intense scrutiny from upstream kernel maintainers.
Userspace integration presents its own set of engineering hurdles. P3S inspects section alignments within binary headers to trigger its behavior. However, modern arm64 binaries are universally aligned to 64 KiB boundaries to ensure broad cross-platform compatibility. The current implementation relies on custom shim wrappers to explicitly force P3S activation, allowing spawned processes to inherit 4 KiB page mappings.
Recognizing these upstream uncertainties, the Asahi team is taking a measured release posture. Until Google clarifies its upstream roadmap and architectural intent, Asahi has stated it will not enable or ship this feature by default in its downstream distribution. The team intends to wait for core mechanisms to be vetted and accepted by mainline Linux before considering a broader rollout.
The progress report also highlighted several other notable hardware milestones. The Apple M3 family graduated from experimental status into full general availability, while the DCP display controller gained sleep/wake support and proper notch-area rendering on MacBooks. The first batch of upstream Thunderbolt patches enabled USB3 and network bridging, and Fedora Asahi Remix achieved a synchronized same-day release alongside upstream Fedora Linux 45.
The ongoing effort to run Windows games on ARM64 is evolving from userspace emulation toward foundational kernel architectural changes. FEX has demonstrated that binary instruction translation is computationally viable; the remaining hurdles sit within the operating system’s memory management bedrock. By swapping out an entire virtual machine for a lightweight register write, P3S eliminates a 20% overhead tax. Once kernel page granularity barriers fall away, cross-architecture gaming can finally drop its heaviest baggage.
References:
- Asahi Linux Official Progress Report (James Calligeros)
- Linux Plumbers Conference 2026 Presentation (Kalesh Singh, Frederick Mayle)
