Asahi Linux 7.3 进展：为 Apple Silicon 自研 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 Networking。你可以插入 USB 设备，或将两台 Thunderbolt 电脑连接起来让它们互相 ping 通，但仅此而已。大多数 Thunderbolt 扩展坞所需的 PCIe 和 DisplayPort 隧道——尚不支持。敬请期待。

我们要向 Sven 致以巨大的感谢，他在其他所有出色工作之间，坚持这项吃力不讨好的任务近 5 年。在 Asahi Linux 上玩零售 PC 游戏，至少可以说是一个痛点。实现这一点所需的软件栈极其复杂。我们需要将 x86/amd64 二进制翻译为 arm64，并且速度要足够快以满足低延迟游戏的需求。大多数情况下，我们还需要处理 Windows API。除此之外，几乎所有游戏都内置了假设的 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 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，但该补丁集大部分可以干净地 rebase 到主线 Linux 上。如果我们把它 rebase 到我们的 Asahi 树上（并修复一些 bug）会怎样？事实证明：

好吧好吧，Battlefront 是一款 22 年前的非常简单的 Direct3D 9.0 游戏。不算什么令人印象深刻的演示，对吧？那这个呢：Wolfenstein: The New Order 是有史以来优化最好的原生 Vulkan 游戏之一，并且作为 64 位游戏使用 WINE 的 ARM64EC 路径，大幅减少了 FEX 需要做的工作。再说一次，如果按技术难度来评判，这也不算令人印象深刻的演示。让我们找点别的。更糟的。32 位的，这样

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