| 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 - pioneer Fuchsia on RISC-V 20%-ers
- cpu@google.com - RISC-V 冠軍
- travisg@google.com - Kernel wrangler emeritus
審查者：
- phosek@google.com (Toolchain)
- shayba@google.com (測試、建構系統)
- mcgrathr@google.com (Zircon)
- dpursell@google.com (韌體)
- mkearney@google.com (說明文件)
- mvanotti@google.com (Security)
已諮詢：
- 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 韌體
核心只會在監督員模式 (S 模式) 下執行，且需要以機器模式 (M 模式) 執行的低階韌體協助。SBI 規格提供多種服務，例如啟動次要核心、計時器和使用遠端柵欄。這項規格通常由開放原始碼韌體實作項目 (例如 OpenSBI) 實作；QEMU 隨附預先建構的 OpenSBI 1.0，Zircon 會將其做為基準。
啟動
在 QEMU「virt」平台上，我們會先啟動 Zircon，這與 arm64 中使用的類似。boot-shim啟動墊片會取得描述 QEMU 設定的 DeviceTree 資料，並根據 ZBI 啟動通訊協定，呈現代表這些詳細資料的 ZBI 項目。視 RISC-V 的需求而定，ZBI 通訊協定中會指定新的 ZBI 項目類型。日後我們可能會使用其他韌體啟動 Zircon。
虛擬記憶體
RISC-V MMU 支援多種模式，可使用不同大小的頁面和頁面表層級上限。一開始，我們只會專注於 sv39，因為這是大多數硬體中實作的基準。在這個模式中，總共有 39 位元的位址空間，Zircon 會使用這些位元提供 38 位元的使用者位址空間。隨著 Sv48 越來越普及，我們可能會擴充 Zircon，以支援更大的使用者位址空間。
目標產品
這項 RFC 建議以「啟動」設定為目標，然後啟用網路堆疊 3 的「minimal」設定，這樣就不會依附於 Go。需要建立「eng」版本的 minimal 設定，以便在不進行進一步修改的情況下，使用標準開發人員工作流程。
驅動程式
如要進行目標設定，我們需要 PLIC、PCI、乙太網路、控制台、PCI 和 RNG 驅動程式。PLIC 和 PCI 驅動程式需要處理，但據信其餘驅動程式可直接使用現有的 Virtio 架構 ARM 驅動程式，這點需要驗證。
慣例
每當提供 RISC-V 標準時 (例如 ELF psABI 或中斷堆疊處理建議)，Fuchsia 都會遵循標準做法，除非這類標準和建議會妨礙以下定義的支援等級。
舉例來說，我們已將 x18 (s2) 指定為陰影呼叫堆疊的保留暫存器。我們會盡力與社群合作，更新 psABI 規格，允許平台保留 x18。
支援等級
支援層級應為 RFC-0111 中所述的「base」層級。 這需要 LLVM、Rust 和上游支援，因此至少可以鎖定「最低」設定。此外，我們也會更新 SDK，讓您能以樹狀結構外開發方式指定 RISC-V。如需完整詳細資料，請參閱 RFC-0111。此外，基本診斷 (例如當機傾印報告) 和互動式偵錯支援也在範圍內。
效能
這項 RFC 不會影響現有架構上的 Fuchsia 效能，因為沒有與架構無關的變更提案。RISC-V 上的 QEMU 效能只會影響 CI/CQ 測試管道的速度，因此效能工作應僅限於讓這個情境合理快速，這主要包括執行測試套件時不會逾時。
安全性考量
我們建議以下列基本安全防護措施為目標：
- 堆疊金絲雀
- 陰影呼叫堆疊
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 和說明文件工作
此外，您還需要持續支付下列費用：
- 建立維護作業
- RISCV 的 CI/CQ 工作
- 基礎架構的增量成本
- 持續進行更高層級的程式庫移植作業，以提供完整支援
由於 RISC-V 仍是相對較新的架構，我們預期在逐步完成堆疊，全面支援 Fuchsia 的過程中，會遇到未知的挑戰。例如虛擬化支援和受信任的執行環境。
由於缺乏伺服器級 RISC-V 硬體，QEMU 模擬速度緩慢，可能難以執行所有相關測試套件，或使用更精細的產品設定。
此外，部分第三方工具和程式庫可能需要額外作業才能與 RISC-V 相容，我們在此並未考量到這點，且可能需要說服上游專案採用 RISC-V，或強制我們維護分支版本。
我們可能會延後支援 RISC-V，直到 64 位元硬體更加成熟為止，但延後支援可能會導致我們無法及時推出適用於生產裝置的硬體，進而降低 Fuchsia 做為 OS 的可行性。RISC-V 是 Aarch64 和 x86-64 最有力的競爭對手，無疑會成為熱門架構，進而降低成本，並提供更多創新自由。等待時間越長，RISC-V 就越有可能以某種方式演進，導致日後移植 Fuchsia 時更加困難或成本高昂。