Asahi Linux 7.3 进展：为 Apple Silicon 自研 Thunderbolt 控制器适配 Linux

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 Networking。你可以插入 USB 设备，或者把两台 Thunderbolt 电脑连起来让它们互相 ping，但也就仅此而已。PCIe 和 DisplayPort 隧道——大多数 Thunderbolt 扩展坞所必需的——尚不支持。不过，请关注后续进展。

我们要向 Sven 致以极大的感谢，他在其他诸多出色工作之间，坚持这项吃力不讨好的苦差事将近 5 年。

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

muvm 最初开发时，假设 DRM Native Context 能让 VM 内部获得接近原生的 GPU 性能。不幸的是，这个假设并不成立。muvm 的性能损失相当显著，原因有很多，视工作负载不同大约在 20% 左右。围绕使用 VM 固有的局限性进行工程化设计也会引入问题；muvm 无法使用 Wayland，I/O 性能慢，并且难以应对某些类型的输入设备。

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

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

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，但该补丁集基本可以干净地变基到主线 Linux 之上。如果我们把它变基到我们的 Asahi 树上（并修复一些 bug）会怎样？结果是：

好吧好吧，Battlefront 是一款 22 年前的非常简单的 Direct3D 9.0 游戏。算不上什么令人印象深刻的演示，对吧？那这个呢：

Wolfenstein: The New Order 是有史以来优化最好的原生 Vulkan 游戏之一，而且作为 64 位程序，它使用 WINE 的 ARM64EC 路径大幅减少了 FEX 需要做的工作。同样，如果以技术难度来评判，这也算不上令人印象深刻的演示。

让我们找点别的。找点……更糟的。找点 32 位的，这样

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）