2026年11月7日，负责将Linux移植到Apple Silicon芯片的Asahi Linux项目发布了Linux 7.3周期进度报告。这份成绩单同时交出了两项跨代进展：M3系列Mac支持正式去除安装器的EXPERT（专家）标志转为全面可用，而最新的M4 Pro/Max与M5芯片不仅向内核邮件列表提交了可引导至TTY字符界面的初始设备树，还彻底打通了底层逆向工程通道。
与以往“先在下游分支魔改、再花数年推向上游”的节奏不同，Asahi团队此次将约13000行代码的AVD硬件视频解码驱动在下游树停留不到3个月便推上内核邮件列表，连同跳票两年的Thunderbolt雷电接口、TI USB-PD与SPMI驱动一道转向上游优先（upstream-first）模式。这说明开源社区对苹果芯片常规模块的逆向已接近工业化流水线，但在GPU微架构大改、私有安全隔离以及PC游戏页表兼容这三座大山面前，真正的深水区博弈才刚开始。
M3转正的温差与上游审查的真相
M3系列Mac去除安装限制后，由于启用了显示协处理器（DCP），一次性解决了性能、续航、系统休眠以及MacBook刘海屏周边区域的显示利用问题。但对于准备拿M3当主力Linux桌面的用户来说，这里的“全面可用”与M1、M2世代的完整体验存在明显温差：苹果在M3世代开启了GPU微架构的“Tick-Tock”大改，目前新组建的逆向团队仅在XDC大会上演示了m1n1初始化M3 GPU并画出一个三角形，距离整合进上游Mesa图形栈并提供日常3D硬件加速还有漫长工期。
普通读者看进度报告很容易产生另一个误判，即以为Linux 7.3主线内核已经内置了报告中大谈的音频与视频解码功能。核查内核邮件列表可知，“提交至上游列表”距离“主线开箱即用”仍隔着严格的审查周期：开发者James Calligeros于11月3日提交的macaudio音频驱动（约3100行代码，含扬声器与耳机插孔支持）目前处于PATCH v4阶段（共22个补丁）；Sofus Forstreuter于10月20日提交的AVD视频解码驱动（覆盖M1至M3的H.264、H.265、VP9及M3的AV1硬解）则处于PATCH v3阶段（共17个补丁），两者均未正式合入Linux主线。
为什么13000行代码的AVD视频驱动不到3个月就能交审，而仅3100行的音频驱动和雷电接口却耗时数年？核心症结在于苹果硬件对Linux既有子系统假设的破坏程度。Linux内核原本的雷电子系统完全围绕Intel通用控制器编写，而苹果在每个USB-C口塞入了一颗运行RTKit固件的定制Cortex-M3核心与专用路由器，甚至将控制器的复位线隐藏在电源管理单元（PMGR）寄存器区间的随机位写入中；哪怕核心开发者Sven耗时近5年将其推向上游并下放给用户，目前也仅支持USB3和雷电网络连接，扩展坞必需的PCIe与DisplayPort隧道依然缺失。
- 提醒.M1/M2持机者可享受日益完善的准主线体验；M3用户目前仅适合代码编写与轻办公，重度图形需求需等Mesa适配；指望外接雷电显卡或DP显示器的用户仍需观望。
在EL1塞进3个虚拟机：攻破M4与M5的安全高墙
苹果从不公开芯片底层文档，Asahi项目能走到今天，全靠自研的m1n1虚拟机监控器（Hypervisor）把正版macOS当成客户机运行，在后台拦截并记录macOS对硬件寄存器的每一次读写。然而从M4到M5，苹果升级了底层硬件安全隔离机制，险些彻底封死这条净室逆向工程的命脉。
行业标准的Arm芯片通常采用TrustZone技术，通过EL3特权级切换安全与非安全状态；但苹果另起炉灶，在硬件层构建了私有的受保护执行框架（GXF）与SPRR权限体系。在M4芯片上，苹果引入了运行于GL2级别的SPTM（安全页表监控器）；到了M5世代，苹果进一步强制要求macOS依赖由Secure Kernel管理的隔离环境Exclaves——连在屏幕上绘制“摄像头使用中”那颗绿点，都被剥离到Exclaves中，通过名为Tightbeam的IPC协议经由SPTM与XNU内核通信，一旦XNU检测不到运行中的SPTM或Exclaves就会直接崩溃（Panic）。
苹果用私有硬件隔离筑起高墙，开源社区用套娃虚拟化拆掉盲盒。
为了不让XNU崩溃并继续追踪硬件寄存器，Sven在此前模拟GXF与SPRR的基础上走出了一步奇招：直接在m1n1所处的EL1特权级下并列拉起3个虚拟机。这种把操作系统、安全监控器与安全内核拆进平级容器的“套娃”架构，成功骗过了M4与M5上的macOS，不仅保住了Linux跟进苹果新芯片的能力，也为外界安全研究人员观察苹果最新Exclaves架构打开了一扇罕见的透明窗口。
甩掉虚拟机玩PC游戏：被Google卡住的圣杯
在Apple Silicon上用Linux玩x86架构的Windows游戏，最大的拦路虎不是指令集转译（FEX和WINE的ARM64EC支持已相当成熟），而是内存页大小冲突：绝大多数PC游戏写死了4 KiB页表假设，而苹果芯片的Linux内核运行在16 KiB页表下。相比之下，苹果自家的macOS之所以能靠Rosetta流畅跑游戏，是因为XNU内核允许用户空间进程按任意页粒度映射内存；而Linux内核强制要求所有进程与内核页大小一致，迫使Asahi此前只能用轻量化虚拟机muvm包裹游戏以提供4 KiB环境，平白折损约20%的性能，且无法使用Wayland、I/O缓慢。
转机来自Google。由于Android生态正从4 KiB向16 KiB页表迁移，Google工程师Kalesh Singh与Frederick Mayle在今年Linux Plumbers大会上提出了名为P3S（每进程页大小）的内核补丁，仅需在进程切换时向Arm架构的转换控制寄存器（TCR）写入对应控制位，就能以近乎零性能损耗在16 KiB内核上原生运行4 KiB进程。Asahi团队将该补丁移植到自家分支后，不仅在摆脱muvm虚拟机的情况下于M2 Max芯片的Mac Studio上将《德军总部：新秩序》跑到144帧以上，连以优化恶劣著称的32位老游戏《侠盗猎车手4（GTA IV）》与《辐射：新维加斯》也成功通过DXVK原生启动。
- 结论.P3S技术证明Apple Silicon跑Linux游戏完全可以抹平20%的虚拟化损耗，但Asahi团队拒绝在现阶段向用户下发该补丁。
克制的背后是清醒的工程边界判断。Google目前的P3S代码为了满足自身商业需求，硬编码了“16 KiB宿主机运行4 KiB进程”的逻辑，且依赖检查二进制文件的4 KiB段对齐元数据——而现代arm64程序（包括运行Windows游戏的64位WINE）普遍采用64 KiB对齐以兼容所有系统。如果Google不愿将其改造为通用方案并推进至Linux主线，Asahi一旦在下游分支贸然集成，未来只会背上沉重的维护技术债。接下来最值得盯住的变量有两个：一是Google会否将P3S泛化并推向上游主线；二是苹果在后续macOS更新中，会否封堵目前部分Exclaves仍可通过命令行参数绕过的调试路径。