Linux 7.2 已经发布了！真是快。让我们深入了解又一份 Asahi Linux 进展报告。今天我们有很多有趣的发展与您分享，所以请泡一杯茶，尽情享受。再次思考不同... Apple Silicon 平台的电力管理基础结构相当复杂。责任在多个硬件模块之间分配，包括 SMC、PMGR 和 PMP，这些模块之前都在这个博客上提到过。虽然支持这些模块对于电源使用很重要，但改善电池寿命的最大障碍之一却是应用核心本身。有多种方法可以将 CPU 核心“休眠”，每种方法都应在特定上下文中使用。使 ARM CPU 核心休眠的最基本方法是使用 Wait For Interrupt (WFI) 指令。这指示核心停止执行，直到被中断源的中断唤醒。虽然这样通过停止核心执行任何代码节省了电力，但核心仍保持供电，并保持足够的状态以便快速恢复工作。因此，WFI 通常仅用于在运行的系统中停放核心。Apple 核心包括一种“深度” WFI 模式，这会关闭更多核心的功能，代价是丧失其状态。我们的下游 cpuidle 驱动程序通过设置该模式下的 WFI，保存核心状态，然后发出 WFI 循环来运作。类似这种厂商特定的电源管理奇特现象相当常见。对于内核维护者来说，解决此类问题有一个标准的方法：电源状态协调接口（Power State Coordination Interface，PSCI）。PSCI 定义了一个标准接口，使操作系统可以调用由系统固件实现的一组定义的 CPU 核心电源管理功能，包括准备它们进入休眠。为了避免在 Linux 内核中出现众多厂商特定的电源管理黑客，arm64 架构特定代码的维护者已要求所有上游硬件必须使用 PSCI 进行电源管理。因此，我们无法将我们的 Apple 特定 cpuidle 驱动程序上游。那么我们为什么还在使用它呢？PSCI 定义了通过哪些“通道”从内核调度对固件的调用。目前内核中支持的两个通道是 SMC（安全监控调用）和 HVC（虚拟机监控调用）指令，这些指令用来将执行权让给更高的异常级别。Linux 内核预计在 EL2 运行，这意味着它的 PSCI 调用必须让位于 EL3 中运行的固件。但是 Apple 的核心并不实现 EL3……由于内核已经在 EL2 中运行，并且没有在 EL3 中运行的固件可供对话，我们就遇到了一些障碍。Linux 无法发出 SMC 或 HVC 指令，因为没有 EL3 可以让出执行权，这意味着我们无法利用 PSCI。能够恰当地管理 CPU 核心的电源对电池寿命和效率至关重要，因此现状显然不可行。一种快速而简单的解决方案是让 m1n1 将内核加载到 EL1，并在 EL2 中托管一个 PSCI 实现。虽然理论上这样可行，但也会破坏许多架构特性，例如虚拟化。我们必须找到其他解决方案…… 如果你仔细想想，m1n1 几乎就像是我们为 Apple Silicon 编写的固件。mBoot（以前称为 iBoot）在 EL2 中启动它，完成它的工作后，再跳转到附加的有效载荷。m1n1 不为自己保留任何内存，也没有必须常驻的代码，因此它的有效载荷可以自由地回收和覆盖该内存。在生产用的 Asahi Linux 系统中，m1n1 加载的是 U-Boot，而不是直接加载内核。我们这样做是为了利用 U-Boot 的 UEFI 实现，允许发行版和用户使用任何他们想要的标准 UEFI 引导加载程序（GRUB、systemd-boot 等）。UEFI 还提供了另一个功能，运行时服务。和旧版 BIOS 中断类似，UEFI 运行时服务为操作系统提供了一种访问源自系统固件代码的方法。阅读 Arm 发布的 PSCI 标准时，人们会注意到它故意在没有参考任何特定通道的情况下定义 API，并且仅列出了 SMC 和 HVC 作为示例。如果我们对这一点进行广义解释，我们可以得出结论，规格允许其他通道……为此，斯文一直在努力实现基于 UEFI 运行时服务的 PSCI 通道。随着 m1n1 的内存区域被切割出来，像其他固件区域一样，这将允许内核在同一异常级别下调用它以获取 PSCI 服务。斯文已经修改了 m1n1，以保留其内存并留下一个 PSCI 实现，同时使其使用的内核补丁已作为 RFC 在邮件列表上发布！请停止思考不同。考虑到 cpuidle 情况直到最近才没有进展，人们可能会认为某个事件催化了这个领域的工作。这个假设是正确的。ARM 规范要求 WFI 循环中的核心应保留所有状态。