RFC-0211：RISC-V 的 Fuchsia

RFC-0211：RISC-V 上的 Fuchsia
狀態已接受
區域
  • 建構
  • 裝置
  • 驅動程式
  • EngProd/基礎架構
  • 韌體
  • 一般
  • 核心
  • 語言與程式庫
  • 安全性
  • 工具鏈
說明

新增 64 位元 RISC-V CPU 支援。
變更
作者
審查人員
提交日期 (年/月)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 的開放式理念相當符合我們針對開放原始碼 Fuchsia 專案的目標，並且協助我們與 RISC-V 環境中的其他相關人員合作。

相關人員

講師：

  • jamesr@google.com

協作者：

  • curtisgalloway@google.com - RFC wrangler
  • revest@google.com, rogerta@google.com - pioneer Fuchsia 的 RISC-V 20%-ers
  • 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 平台。AEMU 支援不在本 RFC 中，因此不支援需要 AEMU 的工作流程或測試。我們將在日後的 RFC 中分別提出特定開發板的支援。

ISA 擴充功能

RISC-V 將常用的 ISA 擴充功能集定義為「設定檔」。我們會配合官方設定檔定義來提供一致的規定，並與 RISC-V 社群討論未來的設定檔定義。

首先，我們只需要 RVA20 設定檔，因為 QEMU 支援這些設定檔。使用者程式碼會假設 RVA20U64 擴充功能適用於所有 CSS 系統，而不需進行執行階段功能檢查。平臺本身需要硬體/韌體才能支援 RVA20S64 設定檔。

我們預期在將 RISC-V Fuchsia 系統部署於硬體之前，會先更新這些政策。

SBI 韌體

核心只會在 Supervisor 模式 (S-Mode) 中執行，且需要機器模式 (M 模式) 中執行的較低層級韌體的協助。SBI 規格提供服務，例如啟動次要核心、計時器及使用遠端圍欄。這個規格通常透過 OpenSBI 等開放原始碼韌體實作來實作；QEMU 隨附預先建構的 OpenSBI 1.0，因此 Zircon 需要做為基準。

啟動程序

在 QEMU "virt" 平台上，我們會從 Zircon 開始啟動，boot-shim與 arm64 所用的類似。啟動輔助程式會取得描述 QEMU 設定的 DeviceTree 資料，並根據 ZBI 啟動通訊協定顯示代表這些詳細資料的 ZBI 項目。針對 RISC-V 需求專屬的新的 ZBI 項目類型會視需要在 ZBI 通訊協定中指定。我們日後可以使用其他韌體啟動 Zircon。

虛擬記憶體

RISC-V MMU 支援具有不同頁面大小和頁面表格層級上限的多種模式。由於 sv39 是大多數硬體中實作的基準，所以我們一開始只會將重心放在 sv39。在這個模式中，Zircon 會使用總位址空間 39 位元，藉此提供 38 位元的使用者位址空間。隨著 Sv48 的可用性日益普及，我們可能也會擴充 Zircon，以支援更大的使用者位址空間。

目標產品

這項 RFC 提議以「啟動」設定為目標，後面接著啟用網路堆疊 3 的「最低」設定，因此 Go 上不會有任何依附元件。我們需要建立最低設定的「eng」變化版本，這樣開發人員不須進一步修改，就能使用標準開發人員工作流程。

驅動程式

針對目標設定，我們需要 PLIC、PCI、乙太網路、主控台、PCI 和 RNG 驅動程式。PLIC 和 PCI 驅動程式需要工作，但我們認為其餘部分可以原封不動地使用以 Virtio 為基礎的現有 ARM 驅動程式，而這需要進行驗證。

大會

每當提供 RISC-V 標準 (例如 ELF psABI 或中斷堆疊處理建議) 時，Fuchsia 都會遵循標準做法，除非這類標準和建議排除瞭如下定義的支援等級 (定義如下)。

舉例來說，我們已指定 x18 (s2) 做為陰影呼叫堆疊的保留註冊。我們會努力與社群合作更新 PSBI 規格，允許平台特別預訂 x18。

支援等級

支援等級必須是 RFC-0111 中所述的「基礎」層級。這項作業需要 LLVM、Rust 和上游，因此可以指定至少「最低」的設定。此外，SDK 也會更新，以便能夠以 RISC-V 為目標進行樹狀結構外開發。詳情請參閱 RFC-0111。此外，當機傾印報告和互動式偵錯支援等基本診斷內容也在說明範圍內。

效能

這項 RFC 不應影響 Fuchsia 對現有架構的效能，因為目前沒有任何架構獨立的變更。在 RISC-V 上執行 QEMU 的效能只會影響 CI/CQ 測試管道的速度，因此這類效能工作應受限於該情境，讓該情境能夠合理快速執行，大部分工作都適合在不逾時的情況下執行測試套件。

安全性考量

建議您鎖定下列基準安全性因應措施：

  • 堆疊初期測試版本
  • 陰影呼叫堆疊

在 RFC 範圍外，KASLR 和架構端管道因應措施。

測試

針對 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 大架構，因此以下項目會產生極大量的一次性工程費用：

  • 支援 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 連接埠較痛苦或較為困難。

先前的圖片和參考資料