Progress Linux 7.2 – Asahi Linux

Linux 7.2 已经发布了！那很快。让我们深入了解另一份 Asahi Linux 进度报告。今天我们为您带来了许多有趣的进展，所以请为自己泡一杯茶并享受吧。思维不同… Apple Silicon 平台的电源管理基础设施同样复杂。职责划分在多个硬件模块之间，包括 SMC、PMGR 和 PMP，所有这些模块之前都曾在本博客中介绍过。虽然支持这些模块对于电源使用很重要，但提高电池寿命的最大障碍之一是应用程序核心本身。 “睡眠”CPU 内核的方法有多种，每种方法都应在特定的上下文中使用。使 ARM CPU 内核休眠的最基本方法是使用等待中断 (WFI) 指令。这告诉内核停止工作，直到它被来自中断源的中断唤醒。虽然这确实通过阻止核心执行任何代码来节省电量，但​​核心仍保持通电状态并保留足够的状态，使其能够极快地恢复工作。因此，WFI 通常仅用于将核心停放在正在运行的系统上。 Apple 内核包含“深度”WFI 模式，该模式会关闭更多内核，但会丢失其状态。我们的下游 cpuidle 驱动程序通过在此模式下设置 WFI 来运行，保存核心的状态，然后发出 WFI 循环。像这样的特定于供应商的电源管理奇怪现象很常见。值得庆幸的是，对于内核维护者来说，有一种标准方法可以处理它们：电源状态协调接口。 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作为示例。如果我们对此进行广泛的解释，我们可以得出结论，这意味着规范允许其他管道……为此，Sven 一直致力于实施基于 UEFI 运行时服务的 PSCI 管道。通过像其他固件区域一样划分 m1n1 的内存区域，这将允许内核回调它以获取 PSCI 服务，即使它运行在相同的异常级别。 Sven 已经修改了 m1n1 以保留其内存并留下 PSCI 实现，并且支持其使用的内核补丁已经作为 RFC 出现在邮件列表中！请停止不同的想法 鉴于 cpuidle 情况直到最近才出现进展，人们可能会认为某些事件已经催化了这一领域的工作。一个是正​​确的。 ARM 规范要求 WFI 循环中的内核应存在