| RFC-0211：RISC-V 上的 Fuchsia | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 添加了对 64 位 RISC-V CPU 的支持。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2023-02-14 |
| 审核日期（年-月-日） | 2023-03-07 |
摘要
此 RFC 提议向 Fuchsia 添加对 RISC-V CPU 架构的支持。建议的董事会名称为 riscv64。
设计初衷
RISC-V 是一种免费的开放式指令集架构，最初由 UC Berkeley 开发，近年来变得越来越受欢迎。RISC-V International 是一家总部位于瑞士的公益组织，其创始成员包括 Google，负责定义 RISC-V 规范。所有工作均通过在 GitHub 上进行的开放协作流程完成，最终规范可供公众免费使用。RISC-V 架构的设计非常灵活，可用于小型微控制器和服务器级 CPU 等各种设备。它具有 32 位和 64 位地址空间变体，并定义了指令扩展集，这些指令扩展集分为多个类别，方便现代操作系统支持。此外，实现还可以为特殊应用定义自定义的非标准指令。
SiFive 等公司最近推出了高性能 64 位内核，这使得 RISC-V 不再仅仅是小型微控制器解决方案，而是进入了 Fuchsia 目前正在进行大量开发的空间。我们认为，现在是 Fuchsia 支持此架构的绝佳时机。通过现在构建强大的 RISC-V 支持，我们将确保 Zircon 和 Fuchsia 从一开始就能支持下一代计算设备。
RISC-V 的开放理念非常符合我们对开源 Fuchsia 项目的目标，有助于我们与 RISC-V 领域的其他利益相关者开展协作。
利益相关方
辅导员：
- jamesr@google.com
贡献者：
- curtisgalloway@google.com - RFC 协调员
- revest@google.com, rogerta@google.com - RISC-V 20%-ers 上的 Fuchsia 先驱
- cpu@google.com - RISC-V 倡导者
- travisg@google.com - Kernel wrangler emeritus
审核者：
- phosek@google.com （工具链）
- shayba@google.com （测试，构建系统）
- mcgrathr@google.com (Zircon)
- dpursell@google.com （固件）
- mkearney@google.com （文档）
- mvanotti@google.com （安全性）
已咨询：
- keir@google.com (Pigweed)
设计
目标硬件
Fuchsia 仅面向 64 位处理器。因此，RISC-V 支持将仅面向 64 位 CPU。在此，我们建议仅以 QEMU virt 平台为目标。此 RFC 中未考虑 AEMU 支持，因此需要 AEMU 的工作流程或测试将不受支持。对特定开发板的支持将在未来的 RFC 中单独提出。
ISA 扩展
RISC-V 将常见的 ISA 扩展集定义为配置文件。我们将使我们的要求与官方配置文件定义保持一致，并与 RISC-V 社区合作制定未来的配置文件定义。
首先，我们仅要求使用 RVA20 配置文件，因为 QEMU 支持这些配置文件。用户代码可以假定所有 Fuchsia 系统上都提供 RVA20U64 扩展，而无需进行运行时功能检查。平台本身需要硬件/固件来支持 RVA20S64 配置文件。
我们预计，在 RISC-V Fuchsia 系统部署到硬件之前，未来的 RFC 会更新这些政策。
SBI 固件
内核将仅在 Supervisor 模式 (S-Mode) 下运行，并且需要运行在 Machine 模式 (M-mode) 下的较低级别固件的帮助。SBI 规范提供了一些服务，例如启动辅助核心、计时器和使用远程栅栏。此规范通常由 OpenSBI 等开源固件实现来实现；QEMU 随附预构建的 OpenSBI 1.0，Zircon 将需要此版本作为基准。
启动
在 QEMU“virt”平台上，我们将从 Zircon 被类似于 arm64 中使用的 boot-shim 启动开始。启动 shim 会获取描述 QEMU 配置的 DeviceTree 数据，并根据 ZBI 启动协议呈现表示这些详细信息的 ZBI 项。将根据需要，在 ZBI 协议中指定特定于 RISC-V 需求的新 ZBI 项目类型。未来，我们可以使用其他固件启动到 Zircon。
虚拟内存
RISC-V MMU 支持多种模式，这些模式具有不同的内存页大小和最大页表级别。首先，我们将仅专注于 sv39，因为它是大多数硬件中实现的基本配置。在此模式下，总共有 39 位地址空间可用，Zircon 将使用这些地址空间来提供 38 位用户地址空间。随着 Sv48 的普及，我们可能会扩展 Zircon 以支持更大的用户地址空间。
目标产品
此 RFC 建议以“启动”配置为目标，然后启用 Netstack 3 的“最小”配置，这样就不会依赖 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 上 QEMU 的 Fuchsia 性能只会影响 CI/CQ 测试流水线的速度，因此性能工作应仅限于使此场景足够快，这主要涉及运行测试套件而不超时。
安全注意事项
我们建议以以下基准安全缓解措施为目标：
- 堆栈 canary
- 阴影调用堆栈
KASLR 和架构侧信道缓解措施不在本 RFC 的范围内。
测试
riscv64 架构支持的自动化测试将来自持续集成，其中 Fuchsia 将在 QEMU virt 平台中启动。
文档
需要对 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 个主要架构，因此会产生大量一次性工程费用，用于：
- 跨 3 种支持的语言的工具链和 build 系统
- Libc、固件和低级别内核支持
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 移植更加困难或令人望而却步。