进度报告：Linux 7.3

我们又见面了。Linux 7.3 已经发布，过去几个月发生了不少事，那就开始新一期 Asahi Linux 进度报告吧！

上游合并继续推进

和往常一样，上游合并工作仍在推进。除了常规的底层 SoC 模块补丁，这个周期有两个重要驱动进入了邮件列表：macaudio 和 avd。把 macaudio 准备到可以提交的程度并不容易。Apple Silicon 设备上的音频子系统相当特殊，为了正确支持它，需要对 ALSA 核心做不少改动。Apple 还使用了一些上游早已支持的扬声器和耳机功放的特殊变体，这些驱动也需要相当大的修改。这些工作我们之前已经详细讨论过很多，现在终于可以把主驱动提交审阅了。驱动和 Devicetree 改动占了我们整个补丁集相当大的一块，大约 3100 行。

AVD 则完全是另一回事。AVD 驱动在我们的下游树里只待了不到 3 个月，就已经上了邮件列表。这是我们迄今为止大型 SoC 组件最快的一次周转，也预示着将来某个时候可以转向「上游优先」的开发方式。这是个好消息，因为 AVD 驱动及相关 Devicetree 改动大约有 13000 行代码。

这个周期出现在邮件列表上的，还有 M4 Pro 和 Max 设备的初始 Devicetree，甚至还有 M5 的，这要感谢 Yureka 不知疲倦的努力。和以往一样，这些初始 Devicetree 非常精简，只够把 SoC 启动到 TTY，但进一步的支持工作正在推进。敬请关注！

在可行的地方，我们也开始转向上游优先的做法。新设备所需的 TI USB-PD 和 SPMI 驱动改动，以及 Thunderbolt 的初步支持，都是先在上游开发的。看到我们对上游合并的专注开始有回报，我们非常激动！

M3 正式可用

上次我们宣布，可以通过 Asahi 安装器的 EXPERT 标志初步支持 M3 系列机器。很高兴地宣布，早期用户几乎没有报告问题，所以 M3 支持现在已经正式可用，不再需要 EXPERT 标志！

我们还对 M3 支持做了不少改进，最值得一提的是启用了 DCP。除了提升性能和续航，这也让我们能在 M3 系列设备上启用睡眠，并且让 MacBook 刘海周围的区域可以使用！接下来几天请留意 m1n1 和内核更新。

拥挤的房子

上次我们预告了在 m1n1 中虚拟化启用 SPTM 的 macOS 版本，这使得在 M4 系列机器上做逆向工程成为可能。M5 带来了新挑战，因为支持它的 macOS 版本都要求使用 Exclaves。

Exclaves 是运行在由 Secure Kernel 控制的隔离环境中的小型应用。在 M5 系列及更新的 SoC 上，macOS 用它们来处理敏感任务，比如在屏幕上绘制「摄像头正在使用」的指示。XNU 通过 SPTM、使用另一种名为 Tightbeam 的 IPC 协议与 Secure Kernel 及其 Exclaves 通信。和 SPTM 一样，如果找不到正在运行的 Exclaves，XNU 就会 panic。这一切在概念上开始和 Arm 自家的 TrustZone 非常相似。

虽然有些 Exclaves 可以通过修改命令行设置绕过，但我们预计并非总能如此。因此 Sven 开始研究如何把这一切塞进 m1n1。第一个思路：把 Secure Kernel 和 Exclave 用户态放进另一个虚拟机，与 SPTM 和 macOS 并排。

哦，成功了，我们现在已经能在 m1n1 下于 EL1 启动三个虚拟机！也许我们可以开始把 m1n1 卖给那些逃离 VMWare 的公司……有了这个，我们现在可以在 M4 和 M5 系列机器上虚拟化并逆向 macOS 了。

你好，三角形（们）！

M3 支持现在在大多数方面已与 M1、M2 持平，但一个非常明显的例外是 GPU。Apple 的 GPU 团队似乎遵循 tick-tock 模式，M3 的 GPU 与 M1、M2 SoC 上的型号相比是一次非常大的改变。我们很久以前提到过，一批新贡献者正在逆向 M3 GPU，但此后就没怎么再说。

在今年的 XDC 上，Alyssa Millburn、Anna Maniscalco 和 TellowKrinkle 做了一场演讲，介绍他们逆向 M3 GPU 的进展。工作已经推进到 m1n1 能成功初始化 GPU，团队也画出了一个三角形！喜欢这些进度报告里「Think Different」环节的读者会觉得这场演讲很有收获：Apple 又一次做出了一些……有趣的选择，要整合进上游 Mesa 需要大量工程投入。如果你对细节感兴趣，非常值得一看。

非常感谢所有让这项工作成为可能的人。更多进展正在路上，敬请期待。

让你久等了吧？

早在 2024 年 1 月，我们犯了一个错误：承诺在一年内支持 Thunderbolt。这种错误我们不会很快再犯。此后两年我们几乎没再提 Thunderbolt，于是问题来了：它在哪儿？

它在邮件列表上！

Thunderbolt 最初由 Apple 和 Intel 共同开发，Intel 负责所需硬件的设计和制造。由于 Intel 以（大体）合理的价格向任何想要的人提供这些控制器，没有人费心去设计自己的。直到最近，大致与该标准移交给 USB-IF 同时，AMD 等公司才决定自研控制器。Apple 当然也不例外。

作为把大部分芯片 IP 收归自研的一部分，Apple 比大多数厂商更早地选择设计自己的 Thunderbolt 控制器。毫不意外，这个控制器当然是一颗运行 RTKit 的 Cortex-M3，配上一个定制的 Thunderbolt/USB4 路由器。所有 Apple Silicon Mac 上每个支持 Thunderbolt 的 USB-C 口都有一个这样的控制器。

由于市面上其他所有 Thunderbolt 控制器都由 Intel 供应，Linux 内核的 Thunderbolt 子系统实际上是围绕它们设计的。它对所运行机器的硬件拓扑做了许多假设，包括硬件能力以及某些寄存器和共享内存区域的访问模式。Apple 的控制器打破了其中许多假设。真棒。

Thunderbolt 控制器还和 PMGR 古怪地耦合在一起。每个控制器的复位线，是通过设置和清除 PMGR MMIO 范围中间的一组位来拉高或拉低的。没有别的硬件模块是这样工作的，我们花了些时间才意识到，这些看似随机的 PMGR 写入并不只是噪声。

幸运的是，Sven 胜任了处理这一切乱七八糟事情的任务，只是比预期多花了一点时间！虽然启用 Thunderbolt 的补丁集是先发往上游的（又一次大胜！），我们也已经把它拉进下游内核，现在正向用户发布！

但有一个问题。目前只支持 USB3、XDomain 和 Thunderbolt 网络。你可以插 USB 设备，或者把两台 Thunderbolt 电脑连起来互相 ping，但仅此而已。大多数 Thunderbolt 扩展坞需要的 PCIe 和 DisplayPort 隧道还不支持。暂时不支持。敬请关注。

我们要向 Sven 致以巨大的感谢，在他其他所有了不起的工作之余，他在这项吃力不讨好的苦差上坚持了将近 5 年。

「圣杯，琼斯博士」

在 Asahi Linux 上玩零售版 PC 游戏，至少可以说是个痛点。实现这一点所需的软件栈极其复杂。我们需要把 x86/amd64 二进制翻译成 arm64，而且要快到足以支撑低延迟游戏。多数情况下还要处理 Windows API。除此之外，几乎所有游戏都默认 4 KiB 内存页大小，以实现某些性能优化。过去几年里，这些问题大多已经解决：

• FEX 进步巨大，在大多数情况下，二进制翻译的性能和可靠性已经几乎不是问题；
• WINE 现在也非常出色。对 ARM64EC 的支持成熟可靠，这意味着 FEX 现在只需要翻译游戏二进制，而不用翻译 WINE 整个 Windows API 实现；以及
• muvm 让我们可以启动一个带 DRM Native Context 的轻量虚拟机，为 x86/amd64 应用呈现 4 KiB 的内存页大小。

muvm 最初开发时，假设 DRM Native Context 能让虚拟机内部获得接近原生的 GPU 性能。不幸的是，这个假设并不成立。出于多种原因，muvm 的性能损失相当明显，视负载大约 20%。绕开使用虚拟机固有限制的工程处理也带来了问题：muvm 不能使用 Wayland，I/O 性能慢，而且对某些类型的输入设备支持不佳。

在这一点上 macOS 完全胜过我们。虽然 FEX 和 Rosetta 之间的性能差距已经缩小，但 XNU 允许用户态进程以任意页粒度映射自己，所以 Rosetta 只需要告诉 XNU 为其子进程映射 4 KiB 页即可。Linux 没有这种灵活性，所有页都必须以与内核相同的粒度映射。虽然去年我们预告过 Windows 游戏可以在 muvm 之外运行，但那依赖 FEX 内部一些难看的 hack，出于可维护性和翻译正确性的考虑，这些 hack 后来已被移除。真扫兴。即便如此，兼容性也时好时坏，很多（大多是较老的）软件仍然无法运行。双倍扫兴。

出于多种原因，Android 目前正在从 4 KiB 页过渡到 16 KiB 页。Google Play 现在要求应用为 16 KiB 系统构建，任何在这类系统上测试不通过的应用更新都不会被批准在 Play 商店发布。那些不再更新的应用怎么办？那些侧载的企业垃圾应用怎么办？

Google 工程师 Kalesh Singh 和 Frederick Mayle 今年在 Linux Plumbers Conference 上就此做了一场非常有意思的演讲。他们的方案很简单：直接修改 Linux，让用户态可以映射 4 KiB 页！

他们在 Android 内核中加入的功能叫 P3S，即 Per Process Page Size（按进程页大小）。在 ARM64 系统上，页表粒度由 Translation Control Registers（TCR）中设置的位控制。P3S 的做法是跟踪每个进程页表的粒度，每当切换到页表大小不同的进程时，就把相应的位写入 TCR。由于这只是一次寄存器写入，而且对「原生」页大小的进程来说是空操作，性能损失实际上为零！

虽然这项工作主要面向 Android，但补丁集基本可以干净地 rebase 到主线 Linux 上。如果我们把它 rebase 到 Asahi 树上（并修几个 bug）会怎样？结果是：

《星球大战：前线》（2004）在 muvm 之外运行，使用 WineD3D

好吧好吧，《前线》是一款 22 年前的非常简单的 Direct3D 9.0 游戏，算不上多惊艳的演示，对吧？那这个呢：

《德军总部：新秩序》（2014）在 muvm 之外运行

《德军总部：新秩序》是一款优化极好的 OpenGL 游戏，而且作为 64 位程序，它走的是 WINE 的 ARM64EC 路径，大大减少了 FEX 要做的工作。同样，如果按技术难度评判，这也不算多惊艳的演示。

那就找点别的。找点……更糟的。找个 32 位的，让 FEX 和 WINE 更费劲。找个也能用上 DXVK 的。找个 bug 多到滑稽、优化烂到在真正的 Windows 机器上都跑不好、要靠社区补丁和命令行开关才能在现代电脑上启动的：

《侠盗猎车手 IV》（2008）在 muvm 之外运行，使用 DXVK

这才像样！但我们还能更糟。我们甚至能跑……Bethesda 的游戏！

《辐射：新维加斯》（2010）在 muvm 之外运行，使用 DXVK

当然，性能仍然参差不齐。《前线》和《德军总部》基本完美运行，后者在 M2 Max Mac Studio 上能跑到 144+ FPS。而 GTA IV 就……不太理想。不过性能仍比使用 muvm 大幅提升，而且总体上去掉虚拟机也应该能消除几类 bug。用这种方式调试 GPU 驱动也应该容易得多。

和往常一样有一个问题，而且不幸的是个大问题。目前的方案是写死的：只针对 16 KiB 宿主机以及其上的 4 KiB 进程。这显然满足 Google 的商业需求，但在内核核心内存管理代码里加入特定页大小的权宜之计，并不适合进入上游。我们不确定 Google 是否打算把这种方法通用化并合入上游，还是会一直作为仅限 Android 的补丁集。因此，在存在这种程度不确定性的情况下，我们不想把它放进下游树发布，让大家对它产生依赖。

它还需要用户态配合。P3S 的工作方式是检查二进制元数据中各段的页对齐。这适用于 Google 的场景，因为 P3S 本来就是给按 4 KiB 页对齐的应用准备的后备机制。然而现代 arm64 二进制按 64 KiB 对齐，因为这能保证与所有原生页大小的系统兼容。因此需要一个 shim 来强制开启 P3S：shim 触发 P3S，其所有子进程都会继承它的 4 KiB 页大小。在我们对 Google 打算如何处理这个补丁集有一定把握之前，不值得花力气去实现它。

我们已经就一些问题联系了 Google，希望很快能有更多消息。

麦克风，但更快

我们为 MacBook 麦克风阵列定制的波束成形器是用 Rust 写的。Rust 的科学计算生态不如 C++ 成熟，这有点麻烦，因为波束成形需要对装满音频采样的缓冲区做实时 FFT 和非常繁重的矩阵运算。成熟的科学计算库都有手工优化的代码，常常使用与目标指令集绑定的 intrinsics。而我们没有这样做，而是依赖编译器在能做的地方自动向量化代码，以达到性能目标。

当我们去掉基于 FFT 的解析变换、换成基于无限脉冲响应（IIR）滤波器的实现时，这套办法失灵了。新实现本应更快，但编译器没能对它自动向量化。Linkmauve 热心出手，为 arm64 和 amd64 都加上了 SIMD 优化代码。再加上 Frédéric Bour 带来的其他性能优化，Triforce 的速度提升到了将近两倍，同时占用的 CPU 时间更少！

跟上节奏

Fedora Linux 45 于 11 月 3 日发布，我们在同一天发布了 Fedora Asahi Remix。这是我们第一次做到与上游同一天发布新版 Fedora Asahi Remix！

以史为鉴

我们为自己的工作深感自豪，并且一直把所有开发放在公开环境中进行。我们尽人力所能地透明地与用户、关注者和资助者沟通。我们的财务是公开的，开发分支是公开的，我们也定期、坦率地公开汇报进展。我们的 IRC 频道和 Matrix 房间是安全的空间，向任何哪怕只对 Asahi Linux 或折腾 Apple Silicon 有一点兴趣的人开放。

我们这样做，是因为我们坚信自由与开源软件，不仅把它当作达成目的的手段，更把它本身当作目的。现代数字世界之所以可能，全靠自由软件运动；现在比以往任何时候都更重要的是，尽我们所能保护自由软件生态，坚守它赖以建立的理想。

有些人可能会惊讶地得知，WINE 最初是以 MIT 许可证发布的。上世纪 90 年代和 2000 年代的自由软件生态与今天大不相同，宽松许可的项目被科技公司视为可以随意掠夺和利用的免费地盘。WINE 也未能幸免，许多被商业化的 WINE 专有分支被各种不良行为者推销和出售。WINE 开发团队越来越担心，这些专有分支虽然完全有权存在，但最终会在生态中造成严重的碎片化，以至于 WINE 本身难以为继。2002 年，WINE 改用 LGPL 重新授权，以阻止更多专有分支出现，并鼓励直接向上游贡献。

Asahi Linux 刚起步时，我们的目标是为 Apple Silicon 平台打造一个自由软件生态。为了方便并鼓励 BSD 和其他自由软件操作系统的朋友参与，我们尽量把尽可能多的代码以宽松的 MIT 许可证授权。

不幸的是，这条路已经走不通了。90 年代和 2000 年代的恶意做法再次抬头，而这一次在很大程度上是由前沿 AI 实验室对高质量训练数据贪得无厌的需求，以及对自由软件社区咄咄逼人的敌意所推动的。

前段时间，我们得知有多起试图利用我们的宽松许可来劫持我们工作的行为，其直接目的是取代这个项目，并激进地把 Apple Silicon 上的 Linux 商业化。在一些极端案例中，开发中的功能代码被直接从我们的个人分支里拿走，不加署名地发布，或者借助 LLM 草草改写以掩盖其来源。MIT 许可证明确允许这样做，也没有任何条款来防范恶意行为者。

因此，我们做出了一个艰难的决定：开始把我们所有仓库迁移到 GNU 通用公共许可证第 2 版或更高版本（GPLv2-or-later）。今后所有 Asahi Linux 代码都只会以强 copyleft 许可证授权。不以史为鉴的人注定重蹈覆辙。

下次见！

一如既往，我们衷心感谢 OpenCollective 和 GitHub Sponsors 上的支持者。正是有了你们慷慨的支持，我们才能投入时间和资源，继续逆向这个平台，并在其上打造世界一流、精致、久经考验的 Linux 桌面体验。你们对我们意义非凡。

James Calligeros · 2026-11-07