| RFC-0211：RISC-V 上的 Fuchsia | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 新增對 64 位元 RISC-V CPU 的支援。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2023-02-14 |
| 審查日期 (年-月-日) | 2023-03-07 |
摘要
這份 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 管理員
- revest@google.com、rogerta@google.com - 在 RISC-V 20%-ers 上開發 Fuchsia 的先驅
- cpu@google.com - RISC-V 冠軍
- travisg@google.com - 退休的核心馴服者
審查者：
- 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 的 workflow 或測試。我們會在日後的 RFC 中提出特定開發板的支援。
ISA 擴充功能
RISC-V 將常見的 ISA 擴充功能組合定義為設定檔。我們會將要求與官方設定檔定義保持一致，並與 RISC-V 社群合作，針對日後的設定檔定義進行合作。
首先，我們只需要 RVA20 設定檔，因為 QEMU 支援這類設定檔。使用者程式碼可假設 RVA20U64 擴充功能可用於所有 Fuchsia 系統，而無需執行時間功能檢查。平台本身需要硬體/韌體支援 RVA20S64 設定檔。
我們預計在 RISC-V Fuchsia 系統部署至硬體前，透過未來的 RFC 更新這些政策。
SBI 韌體
核心只會在 Supervisor 模式 (S 模式) 下執行，並需要在 Machine 模式 (M 模式) 下執行的較低層級韌體協助。SBI 規格提供的服務包括啟動次要核心、計時器和使用遠端區隔。這個規格通常由 OpenSBI 等開放原始碼韌體實作項目實作；QEMU 會隨附預先建構的 OpenSBI 1.0，Zircon 會將其做為基準。
啟動程序
在 QEMU「虛擬」平台上，我們會先讓 Zircon 透過與 arm64 中使用的 boot-shim 類似的 boot-shim 啟動。啟動緩衝區會取得描述 QEMU 設定的 DeviceTree 資料，並根據 ZBI 啟動通訊協定，呈現代表這些詳細資料的 ZBI 項目。我們會視需要在 ZBI 通訊協定中指定特定 RISC-V 需求的新 ZBI 項目類型。日後，我們可以使用其他韌體來啟動 Zircon。
虛擬記憶體
RISC-V MMU 支援多種模式，可搭配不同的頁面大小和頁面表格層級。一開始，我們只會專注於 sv39，因為這是大多數硬體實作的基準。在這個模式中，可用的總位址空間為 39 位元，Zircon 會使用這些位元提供 38 位元的使用者位址空間。隨著 Sv48 的推出範圍越來越廣，我們可能會擴充 Zircon，以支援更大的使用者位址空間。
目標產品
這份 RFC 建議以「啟動」設定為目標，接著使用網路堆疊 3 啟用「minimal」，這樣就不會對 Go 有依附元件。您需要建立最小化設定的「eng」變化版本，讓標準開發人員工作流程可用，而無須進一步修改。
驅動程式
針對指定的設定，我們需要 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 上，Fuchsia 在 QEMU 上的效能只會影響 CI/CQ 測試管道的速度，因此應限制這類效能工作，以便在這種情況下盡可能加快速度，這通常需要執行測試套件，且不會逾時。
安全性考量
我們建議針對下列基本安全防護措施進行調整：
- 堆疊金絲雀
- 陰影呼叫堆疊
這份 RFC 的範圍不包括 KASLR 和架構側邊管道緩解措施。
測試
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 和說明文件
此外，您還需要持續支付下列費用：
- 建構維護
- RISC-V 的 CI/CQ 工作
- 基礎架構的增量成本
- 持續進行更高層級的程式庫移植作業，以便提供完整支援
由於 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 指令集手冊第 II 卷：特權架構
- RISC-V 設定檔