RFC-0211：RISC-V 上的 Fuchsia

RFC-0211：RISC-V 上的 Fuchsia
状态已接受
领域
  • Build
  • 设备
  • 驱动程序
  • 工程产品/基础架构
  • 固件
  • 一般措施
  • 内核
  • 语言和库
  • 安全性
  • 工具链
说明

添加了对 64 位 RISC-V CPU 的支持。
Gerrit 更改
  • 802787
作者
审核人
提交日期（年-月-日）2023-02-14
审核日期（年-月-日）2023-03-07

修改此 RFC

修改 RFC 元数据

总结

此 RFC 提议为 Fuchsia 添加对 RISC-V CPU 架构的支持。提议的面板名称为 riscv64。

设计初衷

RISC-V 是一种免费的开放指令集架构，最初由加州大学伯克利分校开发，近年来越来越受欢迎。RISC-V International 是一家位于瑞士的公益组织，其创始成员包括 Google，定义了 RISC-V 规范。所有工作都是通过在 GitHub 上进行的开放式协作流程完成的，并免费向公众提供最终的规范。RISC-V 架构的设计足够灵活，可以用于小型微控制器和服务器级 CPU 之间的各种配置。它具有 32 位和 64 位地址空间变体，并定义了一组指令扩展，这些指令扩展被划分为便于现代操作系统支持的类别。此外，实现还可以为特殊应用定义自定义非标准指令。

SiFive 等公司最近推出了高性能 64 位核心，这使得 RISC-V 从主要小型微控制器解决方案转移到了 Fuchsia 目前进行最多开发的空间。我们认为现在是 Fuchsia 支持此架构的最佳时机。通过立即构建强大的 RISC-V 支持，我们将确保 Zircon 和 Fuchsia 从新一代计算设备进入市场之初就能支持它们。

RISC-V 的开放理念非常适合我们针对开源紫红色项目的目标，并将帮助我们与 RISC-V 领域的其他利益相关方开展协作。

利益相关方

教员：

  • jamesr@google.com

创作贡献者：

  • curtisgalloway@google.com - RFC wrangler
  • revest@google.com、rogerta@google.com - RISC-V 20%-ers 的 Fuchsia 先锋
  • cpu@google.com - RISC-V 冠军
  • travisg@google.com - 荣誉内核 wrangler

审核者：

  • phosek@google.com（工具链）
  • shayba@google.com（测试，构建系统）
  • mcgrathr@google.com (Zircon)
  • dpursell@google.com（固件）
  • mkearney@google.com（文档）
  • mvanotti@google.com（安全）

咨询人员：

  • keir@google.com（猪草）

设计

目标硬件

Fuchsia 仅以 64 位处理器为目标。因此，RISC-V 支持将仅针对 64 位 CPU。我们提议仅以 QEMU virt 平台为目标。此 RFC 未考虑支持 AEMU，因此需要 AEMU 的工作流或测试将不受支持。对特定开发板的支持将在未来的 RFC 中单独提出。

ISA 扩展

RISC-V 将常见的 ISA 扩展集定义为配置文件。我们将根据官方商家资料定义调整我们的要求，并就未来的商家资料定义与 RISC-V 社区合作。

首先，我们只需要 RVA20 配置文件，因为它们受 QEMU 支持。用户代码可以假定 RVA20U64 扩展程序在所有 Fuchsia 系统上可用，而无需进行运行时功能检查。平台本身需要硬件/固件来支持 RVA20S64 配置文件。

我们预计未来 RFC 会在硬件上部署 RISC-V Fuchsia 系统之前更新这些政策。

SBI 固件

内核将仅在 Supervisor 模式 (S-Mode) 下运行，并且需要在机器模式 (M-mode) 中运行的较低级别固件的帮助。SBI 规范提供了各种服务，例如启动辅助核心、计时器和使用远程栅栏。此规范通常通过 OpenSBI 等开源固件实现来实现；QEMU 附带了预构建的 OpenSBI 1.0，Zircon 会将该 1.0 用作基准。

启动

在 QEMU“virt”平台上，我们将从 boot-shim（类似于 arm64 中使用的工具）启动 Zircon。boot-shim 会获取描述 QEMU 配置的 DeviceTree 数据，并根据 ZBI 启动协议提供表示这些详细信息的 ZBI 项。将根据需要在 ZBI 协议中指定特定于 RISC-V 需求的新 ZBI 内容类型。将来，我们可以使用其他固件启动到 Zircon。

虚拟内存

RISC-V MMU 支持多种模式，这些模式具有不同的页面大小和最大页面表级别。首先，我们只关注 sv39，因为它是在大多数硬件中实现的基准。在此模式下，39 位的总地址空间可供 Zircon 使用，以提供 38 位的用户地址空间。随着 Sv48 的普及，我们可能会扩展 Zircon，以支持更大的用户地址空间。

目标产品

此 RFC 提议先定位“bringup”配置，后跟 Netstack 3 上启用的“minimal”配置，因此对 Go 没有依赖项。需要创建最低配置的“eng”变体，以便标准开发者工作流无需进一步修改即可使用。

驱动程序

对于目标配置，我们需要 PLIC、PCI、以太网、控制台、PCI 和 RNG 驱动程序。PLIC 和 PCI 驱动程序需要改进，但我们认为其余驱动程序可以按原样使用基于 Virtio 的现有 ARM 驱动程序，这需要验证。

惯例

每次提供 RISC-V 标准（例如 ELF psABI 或中断堆栈处理建议）时，Fuchsia 都会遵循这些标准做法，除非此类标准和建议不包括商定的支持级别（如下文中所定义）。

例如，我们已经将 x18 (s2) 指定为影子调用堆栈的预留寄存器。我们将努力与社区合作来更新 psABI 规范，以便专门允许平台预留 x18。

支持级别

支持级别应为“基本”级别，如 RFC-0111 中所述。这需要 LLVM、Rust 和上游支持，以便至少可以针对“最低”配置。此外，该 SDK 也将更新，以便能够进行以 RISC-V 为目标的树外开发。如需了解完整详情，请参阅 RFC-0111。此外，崩溃转储报告和交互式调试支持等基本诊断也在考虑范围之内。

性能

此 RFC 不会影响 Fuchsia 在现有架构上的性能，因为没有提出与架构无关的更改。在 RISC-V 上，Fuchsia 在 QEMU 上的性能只会影响 CI/CQ 测试流水线的速度，因此此类性能工作应进行限制，以使此场景合理快速，这主要涉及在不超时的情况下运行测试套件。

安全注意事项

我们提议采用以下基准安全缓解措施：

  • 金鱼栈
  • 阴影调用堆栈

KASLR 和架构边信道缓解措施不在此 RFC 的讨论范围内。

测试

riscv64 架构支持的自动化测试将通过持续集成（在 QEMU virt 平台中启动 fuchsia）来实现。

文档

需要对 fuchsia.dev 文档进行翻新，以便在很多地方添加 RISC-V，以便常规开发者能够找到提供 RISC-V 专用代码所需的信息。以下是一些示例：

  • “concepts/architecture/architecture_support.md”中有新条目
  • concepts/emulator/index.md 中的图片和白板支持
  • concepts/testing/sanitizers.md 中支持的配置
  • contribute/contributing_to_zircon.md的所有主要目标

缺点、替代方案和未知情况

此方案在 Fuchsia 中添加了第三个主要架构，因此在以下方面会产生大量的一次性工程费用：

  • 支持 3 种语言的工具链和构建系统
  • 库、固件和低级内核支持
  • zxdb和crashpad工作
  • 特定于架构的内核工作
  • SDK 和文档工作

此外，这会产生以下方面的持续费用：

  • 构建维护
  • 针对 RISCV 的 CI/CQ 工作
  • 增加的基础架构费用
  • 正在进行更高级别的库移植，以获得全面支持

由于 RISC-V 仍然是一个相对较新的架构，因此当我们在堆栈中逐步学习以获得全面的 Fuchsia 支持时，我们预计会遇到未知的挑战。虚拟化支持和可信执行环境就是两个这样的例子。

缺少服务器类 RISC-V 硬件会导致 QEMU 模拟速度变慢，并且可能难以运行所有相关测试套件或使用更复杂的产品配置。

此外，某些第三方工具和库可能需要额外的工作来实现 RISC-V 兼容性，我们在这里未考虑这些工作，并且可能需要说服上游项目采用 RISC-V 或强制我们维护分支。

我们可以将对 RISC-V 的支持推迟到 64 位硬件比较成熟之后，但这样做有可能会落后于为正式版设备提议的硬件引入，使得 Fuchsia 作为操作系统的可行性降低。RISC-V 是 Aarch64 和 x86-64 最可行的竞争对手，无疑会成为一个热门架构，从而降低成本并增加创新自由。我们等待的时间越长，RISC-V 就越有可能做出改进，使后期 Fuchsia 端口更困难或更让人望而却步。

早期技术和参考资料