Asahi Linux在最新发布的《Progress Report: Linux 7.2》里,交出了一份听起来很硬核的答卷:开发者Sven Peter想出了一套办法,绕开了苹果芯片天生缺失的一层硬件权限,让Linux终于有希望按标准方式管理CPU睡眠。这原本是横在Asahi面前四年多的一块硬石头——苹果的芯片不实现ARM架构里管电源该用的EL3层,内核想按规矩休眠CPU,连门都摸不到。Sven的方案理论上把这条路凑通了,但截至发稿,对应的内核补丁还只是挂在邮件列表上的RFC,没有合入主线,也没有在任何发行版里默认打开。工程上是一次真正的突破,离用户能感觉到"续航变好"还差着一整个评审周期。
苹果没留的后门,Asahi只能自己搭一个
标准做法是,操作系统想让CPU核心深度休眠,得通过PSCI接口调用系统固件——而固件跑在比内核更高的EL3层。问题是苹果压根没在自家芯片里实现EL3,内核在EL2层喊了半天,没人接。
Asahi的应对思路挺讨巧:让自己的引导程序m1n1留一块内存常驻,伪装成UEFI的"Runtime Service",内核就能在同一权限层级里"回头"调用它,当作PSCI固件来用。这不算标准玩法,PSCI规范里也没明说这条路能不能走,但至少没写死不能走。
苹果没闲着,补丁没进门
更麻烦的是,苹果不是个安静的旁观者。从M4系列开始,苹果在启动阶段就把控制CPU状态保留的"chicken bits"寄存器锁死了。以前Asahi还能软件层面调整,现在锁死之后,M4上标准的WFI休眠指令一执行,核心直接丢状态崩溃。开发者Yureka在M4适配时踩了这个坑,临时加了个内核启动参数绕过,相关补丁已经进了linux-next,但这只是止血,不是根治。
这两件事放在一起看,更接近真实情况:找到一条理论可行的路,和这条路真正铺好通车,中间还隔着上游内核维护者的评审、合并、发行版启用——每一步都可能被苹果下一代芯片的新设计打乱重来。
- 风险.UEFI Runtime Service能不能被ARM64上游接受为PSCI的"第三种conduit",目前没有定论,一旦被拒,整套方案还得另找出路。
社区实测戳破的错觉
原文通篇都是"我们解决了一个难题"的工程叙事,容易让人下意识觉得"新版本=续航变好"。但从社区反馈拼出来的图景要复杂得多。不同机型的实测续航横跨了很大区间:M1 13寸机型大约7到8小时,电池已经老化的M1 Air掉到5小时左右,M2 Air能到8到10小时,M2 Max反而只有6到7小时,一旦跑编译任务续航还会明显跳水。
社区反复提到的核心痛点其实不是活跃使用时的功耗,而是合盖待机——很多用户干脆放弃休眠,选择直接关机,因为合盖之后掉电太快。这次7.2的cpuidle工作瞄准的是空闲循环里的核心睡眠状态,跟合盖待机是两套不同的问题,报告里完全没提。
找到了绕过EL3的路,不等于合上盖子电池就不再哗哗掉。
还有一个容易被拿来当"证据"的陷阱:网上流传的Asahi对macOS能效对比数据,大多还是Phoronix在2022年针对M2跑的那一轮基准测试,当时Linux这边还拿不到SoC的功耗遥测数据,能效比结论本身就存疑,更别说四年过去,GPU栈和电源管理已经改了一轮又一轮。拿这份旧数据来说"Asahi已经追上macOS",本身就站不住。
现在能不能装,分机型看
M3系列的支持已经接近收尾,摄像头、麦克风、USB3、雷雳、显示控制器这些外围功能基本理清,官方发布只是时间问题。M4和M5还停留在早期阶段,NVMe和PCIe枚举刚跑起来,多核启动的崩溃才刚修完,离日常可用有明显距离,安装器里也还没开放这两个系列。视频硬解方面,AVD对主流编码已经能稳定解码,但Fedora Asahi Remix没有默认打开硬解,直通显示还卡在KWin把苹果GPU和显示控制器当成两块独立显卡处理的假设上,这一步最快也要等到Plasma 6.8。
- 结论.如果只关心"能不能流畅日常用",M3等官方发布再入手更划算;M1/M2老用户想要的续航改善,这次的技术突破还没到能装进发行版的那一步。
接下来真正该盯的,是PSCI这份RFC补丁能不能被ARM64上游维护者接受——这将决定苹果这类不实现EL3的平台以后要不要在内核里单独开一条路子。