在 Apple Silicon 设备上运行 Windows 游戏，主要的性能开销早已离开指令翻译。真正的技术阻碍，来自 Linux 内核对内存页尺寸的全局锁定。2026 年 11 月 7 日，Asahi Linux 团队发布 Linux 7.3 进度报告。开发者借助 Android 的 P3S 补丁，成功让 x86 游戏脱离虚拟机运行。
三层开销吃掉20%性能，瓶颈卡在4K内存页
在 Asahi Linux 上玩 PC 游戏，过去需要叠三层运行环境。底层的 FEX 负责把 x86 指令动态翻译为 arm64 指令。中间层的 WINE 负责承接 Windows API 调用。顶层的 muvm 则通过微型虚拟机，为老旧程序模拟出 4 KiB 内存页。
设计 muvm 的最初意图，是利用 DRM Native Context 提供接近原生的图形吞吐。工程实测打破了这个预期，虚拟化层带来了约 20% 的性能折损。多层转译叠加虚拟机损耗后，硬件原本的图形算力被吞掉了五分之一。
除了帧率损失，虚拟机架构还引发了诸多外围问题。muvm 无法正常适配 Wayland 桌面协议，窗口管理与剪贴板经常失去响应。虚拟化文件系统的 I/O 吞吐显著下滑，手柄等外设输入也难以稳定映射。
macOS靠系统放行，Linux被全系统同页锁死
老游戏依赖 4 KiB 内存页，属于 x86 架构历史包袱。早期的 Windows 游戏与 32 位程序假定系统页尺寸固定为 4 KiB。很多程序的内存分配器直接把 4096 字节硬编码进了二进制逻辑。运行在更大页面的系统上，程序会因为内存越界直接崩溃。
Apple Silicon 硬件默认采用 16 KiB 内存页。macOS 依靠 XNU 内核灵活的虚拟内存设计，允许用户态进程自定义映射粒度。Rosetta 启动 x86 游戏时，内核单独为该子进程分配 4 KiB 地址空间，全系统无需妥协。
Linux 内核在此处遇到了底层设计分歧。传统 Linux 要求全系统所有进程保持统一的内存页大小。去年 Asahi 曾在 FEX 内部尝试模拟 4 KiB 环境。为了兼顾代码维护与翻译正确性，团队随后移除了这些临时补丁。
ARM64寄存器拨一下，进程自带页大小
打破僵局的动力来自移动生态。Android 系统正在推进从 4 KiB 页面转向 16 KiB 页面的迁移。Google Play 要求新应用适配 16 KiB 架构，大量缺乏维护的老应用因此面临闪退。Google 工程师不得不寻找在 16 KiB 内核上兼容 4 KiB 进程的通用解法。
在 Linux Plumbers Conference 上，Google 工程师提出了 P3S 机制。这项技术全称为按进程页大小（Per Process Page Size）。ARM64 架构的页表粒度由转换控制寄存器（TCR_EL1）内的特定标志位决定。硬件本身其实支持动态切换翻译粒度。
P3S 补丁在内核中跟踪每个进程所需的页表粒度。调度器执行上下文切换时，系统顺便将对应配置写入 TCR 寄存器。单次寄存器写入对原生进程几乎等同于空操作，带来的 CPU 开销接近于零。 这种硬件级切换直接瓦解了维持虚拟机的必要性。
四款老游戏脱离虚拟机，帧率跑满144 FPS
Asahi 团队将 P3S 补丁移植到自身的 Linux 7.3 内核分支。几款极具代表性的老游戏迅速完成了脱离虚拟机的原生实测。2004 年发布的《星球大战：前线》在 WineD3D 配合下平稳启动。渲染画面正常呈现，没有出现过往的内存寻址报错。
图：《星球大战：前线》（2004）在 muvm 之外运行，走 WineD3D。来源：Asahi Linux 官方进度报告
图形负载更高的《德军总部：新秩序》展示了更惊人的释放效果。在搭载 M2 Max 芯片的 Mac Studio 上，游戏帧率轻松越过了 144 FPS。脱离虚拟机直接挽回 20% 图形损耗，ARM64 翻译层足以支撑高刷游戏。
图：《德军总部：新秩序》（2014）在 muvm 之外运行，M2 Max Mac Studio 上 144+ FPS。来源：Asahi Linux 官方进度报告
团队还测试了兼容性向来脆弱的 2008 年作品《GTA IV》。这款 32 位老游戏在真机 Windows 上往往都需要社区补丁才能运行。借助 DXVK 转译 Vulkan，游戏在脱离 muvm 后流畅度获得了飞跃式改善。一同测试的《辐射：新维加斯》同样摆脱了虚拟机卡顿。
图：《GTA IV》（2008）在 muvm 之外运行，走 DXVK。32 位老游戏，原文拿它当「故意找最难的样本」的案例。来源：Asahi Linux 官方进度报告
丢掉虚拟机不仅换来了流畅帧率，还大幅减轻了驱动工程的调试负担。过去排查渲染错误需要跨越宿主驱动与客体驱动两套堆栈。现在图形指令直接通向原生驱动，GPU 故障的定位周期缩短了数倍。
硬编码临时补丁进内核，上游合并仍存变数
P3S 虽然成效显著，目前仍然处于实验性的工程阶段。当前补丁被硬编码为 16 KiB 宿主配合 4 KiB 进程。这套实现主要契合 Google 自身的商业诉求，缺乏通用架构抽象。将特定尺寸的补丁强行植入内核内存管理核心，势必遭遇上游维护者的严苛审视。
用户态层面的配合同样充满工程挑战。P3S 依赖二进制文件的段属性进行判断。现代 arm64 二进制文件普遍采用 64 KiB 边界排布。当前系统需要编写专门的垫片工具强制开启 P3S，才能让子进程正确继承 4 KiB 页面。
面对上游变数，Asahi 团队保持了克制的工程发布节奏。在 Google 明确上游合流路线图之前，Asahi 明确表示不会在下游发行版中默认推送该功能。团队选择等待核心机制被主线内核接纳，再考虑全面铺开。
同期报告还披露了多项硬件进展。M3 系列芯片脱离了实验标记正式受支持，DCP 显示引擎实现了休眠唤醒与刘海区域控制。Thunderbolt 首批补丁支持了 USB3 与网络互联，Fedora Asahi Remix 也实现了与 Fedora 45 官方同日发布。
ARM64 运行 Windows 游戏的工程演进，正在从用户态模拟走向内核底座改造。FEX 证明了指令转译的高效，剩下的阻碍落在了操作系统的内存管理基石上。P3S 用微小的寄存器操作换掉虚拟机，消除了两成损耗。当内核层面的页粒度束缚被打破，跨指令集游戏才算真正卸下沉重包装。
参考链接：
- Asahi Linux 官方进度报告（James Calligeros）
- Linux Plumbers Conference 2026 演讲（Kalesh Singh, Frederick Mayle）
