Hacker News 中文摘要

RSS订阅

朝日Linux进展报告:Linux 7.2 -- Asahi Linux Progress Report: Linux 7.2

Asahi Linux发布了7.2版本,重点改进了Apple Silicon平台的电源管理,通过优化CPU核心休眠模式(如深度WFI)来提升电池续航表现。

正文

好的,这是根据您的要求,对原文主要内容进行的中文重述,保留了关键细节,并删减了与主题无关的冗余内容。


标题:Linux 7.2 进度报告 - Asahi Linux

核心内容:

1. CPU 电源管理的突破:PSCI 新方案

Apple Silicon 的电源管理架构复杂,其 CPU 核心的休眠方式(如 WFI 指令)与 ARM 标准不同。Linux 内核要求所有上游硬件必须使用标准的 PSCI(电源状态协调接口)进行电源管理,但 Apple 的芯片缺少实现 PSCI 所需的 EL3 异常级别,导致我们无法直接使用。

为解决此问题,开发者 Sven 提出了一种创新方案:利用 UEFI 运行时服务作为 PSCI 的新“通道”。通过让 m1n1(Asahi 的引导固件)在启动时预留内存并实现一个 PSCI 服务,Linux 内核可以在运行时回调该服务,从而绕过对 EL3 的需求。相关补丁已作为 RFC 提交到内核邮件列表。

2. M4 芯片的 WFI 问题与解决方案

ARM 规范要求核心在 WFI 循环中保留所有状态,但 Apple Silicon 默认并非如此。从 M4 系列开始,Apple 锁定了控制此行为的寄存器,导致调用 WFI 会使核心丢失状态并崩溃。开发者 Yurkea 发现此问题后,添加了一个内核命令行参数,允许在早期初始化阶段使用空循环来停放核心,直到专用的 cpuidle 驱动接管并妥善保存状态。相关补丁已进入 linux-next。

3. 攻克 M4/M5 的 SPTM 安全机制

Apple 的 SPTM(安全页表监视器)是一个硬件级安全功能,它将页表管理隔离在 GXF(守卫执行框架)的 GL2 异常级别中。XNU 内核必须与 SPTM 通信,否则会崩溃。这导致 m1n1 虚拟机监控器在 M4 及以上设备上失效。

得益于 Sven 早期对 SPRR 和 GXF 的逆向工程,他成功教会了 m1n1 虚拟机监控器模拟这些硬件特性。现在,m1n1 可以加载 Apple 的 SPTM 固件,然后加载 XNU,并像在旧设备上一样监控其行为,尽管追踪速度会稍慢。这确保了未来新硬件的适配工作可以继续进行。

4. M3 系列适配进展

  • 摄像头与麦克风:M3 Max 的 ISP(图像信号处理器)和 M3 系列的麦克风(新增“高频”抽取器)均有微小改动,开发者 chaos_princess 已为 Linux 驱动添加了相应支持,实现了全系列设备的摄像头和麦克风功能。
  • USB-C 与雷电:M3 Pro/Max 使用了新的 ACE3 端口控制器,它通过 SPMI 总线通信。开发者 mildsunrise 和 chaos_princess 发现其寄存器与旧款 CD3217 基本相同,只是接口不同。目前 SPMI 接口和 ACE3 驱动均已正常工作,为 M3 系列带来了 USB 3.0 和雷电支持。
  • GPU 与显示控制器:M3 系列将使用 macOS 14.8.3 的固件 ABI。DCP(显示协处理器)的支持已接近与 M1/M2 使用的 macOS 13.5 ABI 相同的功能水平。官方即将发布 M3 的正式支持版本。

5. M4 和 M5 的初步适配

开发者 Yureka 正在推进 M4 和 M5 的适配工作。除了解决 WFI 问题,还修复了 Apple NVMe 控制器固件的破坏性变更,使得 NVMe 存储可以正常工作。PCIe 总线也已能正常枚举设备,并修复了多核启动时导致内核崩溃的问题。目前 M4/M5 的适配尚处于早期阶段,暂未在安装器中启用。

6. 桌面视频解码的挑战与进展

  • AVD 解码器:开发者 sofus 进一步完善了 AVD(Apple 视频解码器)驱动,H.264、H.265 和 VP9 格式在 M1/M2 上已基本稳定工作。
  • 桌面集成难题:AVD 使用 V4L2 Stateless API,但桌面软件(如浏览器)主要支持 VA-API 或 Vulkan Video。为此,sofus 复刻并修复了一个被废弃的 VA-API 到 V4L2 Stateless 的翻译层,使得支持 VA-API 的软件(如 GStreamer)能够利用 AVD 进行硬件解码。该功能尚未默认启用,且暂不支持 Firefox 的沙箱。

7. 迈向直接扫描输出

为提升能效,目标是让 AVD 解码后的帧缓冲区能被 DCP 直接扫描输出,无需经过 GPU 和 CPU 的多次拷贝。这要求所有硬件块(GPU、DCP、AVD)支持相同的帧缓冲格式(Apple 的 Interchange 格式)。

  • 进展:AGX(GPU)驱动已具备 Interchange 格式的基础支持。开发者 Oliver Bestmann 和 James Calligeros 正在为 DCP 内核驱动和 Mesa 驱动(Asahi 和 Honeykrisp)启用该格式。结合 DCP 已支持的 Y'CbCr 和覆盖平面功能,AGX 渲染的帧缓冲区已能直接扫描输出到 DCP。AVD 输出 Interchange 格式的能力也正在研究中。
  • 障碍:KDE Plasma 的合成器 Kwin 将 AGX 和 DCP 视为“多 GPU”配置,因此目前完全禁用了基于 DMA-BUF 的直接扫描输出。Kwin 开发者正在积极改进,该功能有望在 Plasma 6.8 中启用。

8. 持续上游化

Asahi Linux 团队持续将补丁提交到 Linux 主线内核。近期上游化的内容包括:与扬声器安全功能相关的 I2S 外设变更、启用基于 SMC 的硬件监控驱动的设备树补丁,以及针对 macOS 27 引入的 SMC 固件接口变更的修复。

致谢

感谢 GitHub Sponsors 和 Open Collective 的支持者,他们的资助为开发者提供了必要的硬件,使得 AVD 支持、M4 适配等成果成为可能。

评论

根据评论内容,总结如下:

主要观点与论据:

  1. 项目进展令人赞叹:多位评论者(MBCook、djfergus、owaislone)高度认可Asahi Linux在Apple Silicon上的逆向工程和驱动开发成果,认为其进展迅速且令人兴奋。关键引用:MBCook "Amazing progress as usual";djfergus "Fantastic to see the progress and a fascinating detailed write-up"。

  2. 技术挑战与兼容性问题:megous指出VA-API与v4l2-requests不匹配,因为VA-API会预计算部分编解码信息,而v4l2-requests期望原始比特流。关键引用:megous "va-api is not a good match for v4l2-requests"。

  3. 对Apple安全策略的认可:djfergus认为Apple在安全上的投入解释了其不支持替代操作系统的原因。关键引用:djfergus "You have to appreciate the effort Apple puts into security"。

  4. 用户期待与感恩:JLO64和LoganDark表达了对Asahi Linux的感激和期待,尤其是M3/M4设备的支持。JLO64提到"seriously underestimated the amount of effort",LoganDark期待"hypervisor now works on M4"。

  5. 对电池续航的担忧:owaislone强调电源管理是日常使用关键,Linux在此方面传统上表现不佳。关键引用:owaislone "Battery life would be a huge differentiator"。

不同观点平衡: - 正面:多数评论对项目进展和技术突破表示赞赏,认为其克服了巨大困难。 - 负面/谨慎:megous指出技术兼容性问题;owaislone担忧电源管理;JLO64承认低估了工作量。 - 中立:djfergus既肯定进展,也理解Apple的安全立场。

总结: 评论整体对Asahi Linux的进展持积极态度,认可其逆向工程和驱动开发成就,同时指出技术兼容性、电源管理及Apple安全策略带来的挑战。用户期待未来功能完善,但承认实现全面兼容仍需大量努力。