| 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% 时间内率先使用 Fuchsia
- cpu@google.com - RISC-V 专家
- travisg@google.com - 内核管理员
Reviewers:
- 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 支持这些配置文件。用户代码可以假定 RVA20U64 扩展程序在所有 Fuchsia 系统上都可用，而无需进行运行时功能检查。平台本身需要硬件/固件支持 RVA20S64 配置文件。
我们预计在 RISC-V Fuchsia 系统部署到硬件之前，会通过未来的 RFC 更新这些政策。
SBI 固件
内核将仅在 Supervisor 模式 (S-Mode) 下运行，并且需要在 Machine 模式 (M-mode) 下运行的较低级别固件的帮助。SBI 规范提供服务，例如启动辅助核心、计时器和使用远程栅栏。此规范通常由 OpenSBI 等开源固件实现；QEMU 附带预构建的 OpenSBI 1.0，Zircon 将需要将其用作基准。
启动
在 QEMU“virt”平台上，我们将首先通过与 arm64 中使用的 boot-shim 类似的 boot-shim 启动 Zircon。引导补丁会获取描述 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 种语言的工具链和构建系统
- libc、固件和低级内核支持
zxdb和crashpad的工作原理- 架构专用内核工作
- SDK 和文档工作
此外，您还需要持续支付以下费用：
- 构建维护
- CI/CQ 适用于 RISCV
- 基础架构的增量费用
- 持续进行更高级别库移植，以实现全面支持
由于 RISC-V 仍是一项相对较新的架构，因此在向上游堆栈推进以实现全面的 Fuchsia 支持的过程中，我们预计会遇到未知的挑战。虚拟化支持和可信执行环境就是这类示例中的两个。
缺少服务器级 RISC-V 硬件会导致 QEMU 模拟速度缓慢，并且可能会导致难以运行所有相关测试套件或使用更复杂的产品配置。
此外，某些第三方工具和库可能需要进行额外的工作才能实现 RISC-V 兼容性，而我们在此处并未考虑到这一点，这可能需要我们说服上游项目采用 RISC-V，或者迫使我们维护分支。
我们可以推迟支持 RISC-V，直到 64 位硬件更加成熟，但推迟可能会导致 Fuchsia 落后于为正式版设备推出的硬件，使其作为操作系统的选择变得不太可行。RISC-V 是 Aarch64 和 x86-64 最具竞争力的架构，这无疑会使其成为一种流行的架构，从而降低成本并让创新更加自由。等待的时间越长，RISC-V 演变的可能性就越大，这可能会导致后续的 Fuchsia 移植变得更加困难或不可行。
在先技术和参考文档
- 概念验证分支
- 将 Linux 移植到 RISC-V
- 将 LK 移植到 RISC-V
- RISC-V SBI 规范
- OpenSBI 参考实现
- RISC-V 调用规范
- RISC-V 指令集手册第 2 卷：特权架构
- RISC-V 配置文件