| RFC-0249：平台中的 crosvm 支援 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這份 RFC 建議將 crosvm 設為 fuchsia 平台支援的一流模擬器，除了 qemu 和 femu 之外。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-04-24 |
| 審查日期 (年-月-日) | 2024-05-31 |
摘要
本文件建議將 crosvm 新增為 Fuchsia 專案支援的系統設定。這可讓我們持續在 crosvm 上測試 Fuchsia，並將我們致力於讓 crosvm 在 ToT 運作的承諾編碼化。
提振精神
根據官方文件，crosvm 是類似於 QEMU-KVM 或 VirtualBox 的託管 (又稱為 type-2) 虛擬機器監控器。它支援多種架構，包括 x86_64 和 arm64，以及多個硬體加速後端，包括 Linux KVM。
部分 Fuchsia 使用者已在以 crosvm 為基礎的模擬器中採用 Fuchsia，我們預期這類使用者會隨著時間增加。crosvm 支援功能可讓我們針對這些硬體的 crosvm 實作測試多個驅動程式。雖然我們已支援 QEMU、FEMU、machina 和 GCE，可用於各種虛擬化裝置的各種實作方式，但每種實作方式都有其特殊之處，而且在任何一個模擬器環境中運作的軟體，不保證會在其他環境中運作。為確保不會影響 crosvm 使用者，我們需要在 Fuchsia 的測試基礎架構中，啟用 Fuchsia 針對 crosvm 的自動化測試。
有些裝置則是 Crosvm 支援的裝置，但我們尚未支援其他模擬環境。
此外，我們需要讓驅動程式庫開發人員更輕鬆地編寫及維護在以 crosvm 為基礎的環境中使用的驅動程式。目前這項功能需要在樹狀結構外以產品為導向的環境中執行 Fuchsia。這種做法無法擴充。
最後，某些技術 (例如 x86 的 64 位元 Linux 開機通訊協定) 並未受到任何現有硬體目標的支援。因此，我們尚未實作支援此類功能的 Linux 開機 shim，因為無法進行測試。
相關人員
協助人員：
neelsa@google.com
審查者：
- cja@google.com
- jamesr@google.com
- mcgrathr@google.com
- olivernewman@google.com
- wittrock@google.com
諮詢：
列出應審查 RFC 但不需要核准的人員。
- cpu@google.com
- costan@google.com
- diserovich@google.com
- wilkinsonclay@google.com
社會化：
這個 RFC 已通過 Engprod 團隊的設計審查。此外，我們在調查期間也與所有主要利害關係人聯絡。
需求條件
- 我們必須確保不會讓使用以 Crosvm 為基礎的模擬器的 Fuchsia 客戶發生問題。
- 我們必須在 crosvm 中同時支援 x86_64 和 aarch64 架構。
- 我們必須在 x86_64 和 aarch64 上支援 64 位元 Linux 開機通訊協定。
- 我們必須支援 crosvm 的 Linux KVM 後端。其他後端會很不錯。
- 驅動程式開發人員應可輕鬆測試驅動程式，以便針對驅動程式所寫入的硬體，實作以 crosvm 為基礎的實作項目。
設計
我們會將 crosvm 整合至 Fuchsia 結帳系統，做為 CIPD 預先建構的內容，並新增對 ffx 啟動 crosvm 的支援，最後設定相關機器人，在提交前和/或提交後執行。
實作
啟用和 64 位元 Linux 啟動 shim
為了啟動對 crosvm 的支援，我們必須先啟用 Fuchsia 在 crosvm 上啟動的功能。crosvm 目前只支援提供自訂的啟動載入程式或 64 位元 Linux 啟動通訊協定。Fuchsia 目前支援提供以 EFI 為基礎的啟動載入程式，以及多重啟動和 32 位元 Linux 啟動通訊協定。這組不重疊的啟動選項可防止 Fuchsia 目前在 crosvm 上啟動。因此，要支援 crosvm，第一步是針對 crosvm 執行啟動活動，並為 64 位元啟動通訊協定實作另一個啟動 shim。
值得一提的是，這個問題只會發生在 x86 上。Fuchsia 會在 aarch64 的 crosvm 上啟動。不過，由於 crosvm 預設僅支援硬體加速虛擬化，因此一般 Fuchsia 開發人員很難在 aarch64 下實際在 crosvm 上執行 Fuchsia。雖然我們已證實，crosvm 在過去能夠使用 arm64 Linux 啟動墊片啟動 Fuchsia，但可能還需要進行額外工作，才能確保繼續啟動。
除了啟動補丁工作之外，可能還需要針對相關儲存空間和網路驅動程式進行一些工作，確保裝置可與 ffx 和基礎架構搭配運作。我們會在完成 bootshim 工作後，揭露這項工作，而這項工作很快就會針對 x86_64 推出。我們可能需要 crosvm 團隊的支援，才能將任何剩餘的必要修正項目納入程式碼。
Crosvm 預先建立的輪替程式
系統會設定新的建構工具，從上游 crosvm 存放區提取最新來源，啟用相關功能來建構，然後將最終構件上傳至 CIPD。
更新者會負責更新整合存放區，確保未來的 jiri update 指令會傳送更新版的 crosvm 二進位檔。
ffx emu 支援使用 crosvm 做為替代引擎
ffx emu start --engine 標記會新增其他選項，讓系統選擇 crosvm 而非 qemu 或 femu。ffx emu 預設會向使用者顯示的特定裝置組合，會盡可能與 crosvm 的實際樹狀結構用途相符。由於 Crosvm 有許多使用者，因此我們可能需要支援多種裝置設定。
我們已在 fx run-boot-test --crosvm 中提供部分支援，但您可以新增選用的 fx crosvm 指令包裝函式，進一步簡化這個工作流程。
CI/CQ 建構工具
一旦平台能夠在 crosvm 上啟動 Fuchsia，我們就會推出建構工具，確保 crosvm 支援功能能繼續正常運作。
就我們的目的而言，由於 minimal.x64 產品/電路板組合可與 crosvm 搭配運作，我們可以將用於 qemu 的建構工具重新用於此，因此不需要其他建構工具。
這些建構工具一開始會是 FYI 建構工具，但如果證明穩定後，我們可以將其更新為封鎖型，這也是建立新的封鎖型建構工具的一般程序。
這些建構工具是否在 CI 或 CQ 中執行，以及總共建立了多少個建構工具，都超出本提案的範圍。
此外，我們應該嘗試讓 bringup.x64 建構工具在 crosvm 上執行啟動測試，因為這樣可盡量減少潛在的啟動時間錯誤。
測試
我們必須在 CI 和/或 CQ 中執行的測試，僅限於下列用途：
- 重新啟動和關機測試
- Zircon 核心測試
- 裝置列舉測試，可確保所有周邊硬體列舉正確。
- 系統測試，可確保周邊裝置驅動程式正常運作。
值得注意的是，目前在 QEMU 上執行的密封測試不需要在 crosvm 上重複執行。
在大多數情況下，我們可以透過在測試中顯示的 tests_specs 中指定新環境，來完成此測試區隔。
目前執行的重新啟動和關機測試是主機測試，且對 qemu 有嚴格依附元件，我們需要解決這個問題。此外，這些測試無法在 arm64 機器人上執行，因此我們也需要解決這個問題，確保適當的測試涵蓋率。
額外的周邊裝置啟動
除了啟用 CI/CQ 機器人的必要裝置組合之外，我們還想投資其他周邊裝置，以便支援客戶的使用情境。這些周邊裝置的完整組合超出本提案的範圍。可實作的周邊裝置包括：
- virtio-gpu
- virtio-balloon
- cmos-rtc
成效
我們應確保 Fuchsia 除了具備功能性之外，在 crosvm 上也能提供良好效能。如果啟動速度緩慢，或 virtio 驅動程式在負載時占用過多 CPU，我們就需要進行一些分析和最佳化作業，確保使用 crosvm 的客戶能獲得所需的效能。
人體工學
這項提案可讓驅動程式庫程式開發人員更輕鬆地針對驅動程式目標硬體的 crosvm 實作測試驅動程式。
回溯相容性
不適用。
安全性考量
不適用。
隱私權注意事項
不適用。
測試
這項提案的目的是在平台中新增 crosvm 支援，並在 CI/CQ 中新增相關的自動化測試涵蓋率。
說明文件
請更新 ffx emu 說明文件，反映對 crosvm 引擎的新支援。此外，您應建立支援模擬器的新頁面，說明對 crosvm 的新支援功能。
缺點、替代方案和未知事項
替代方案：不採取任何行動，繼續使用現有的模擬器做為支援的 Proxy
最簡單的做法是什麼都不做，並依賴 qemu 和/或 femu 來確保 virtio 驅動程式繼續正常運作，並視需要在 crosvm 上手動測試。這個選項可讓我們確信我們的 crosvm 支援不會影響 OOT 使用者，但由於現有的模擬器應與 crosvm 共用大部分行為，因此很少會發生中斷情形。
替代方案：請嘗試讓 crosvm 正式支援 Fuchsia
其他作業系統不會特別支援 crosvm。相反地，crosvm 會嘗試直接支援這些作業系統，方法是將其行為與這些作業系統中的現有驅動程式相符。我們可以請求 crosvm 以相同方式支援 Fuchsia。不過，Fuchsia 比其他主要作業系統更為小眾，因此要說服 crosvm 自行提供這類支援，恐怕不太容易。
根據我們在供應商啟動韌體 (甚至是開放原始碼韌體，例如 CrOS 深度充電) 方面的經驗，要實作並維護可靠的 Fuchsia 專屬啟動支援功能，可能會遇到困難。
另一個缺點是，它不會為我們提供 crosvm 的 Linux 啟動支援，而這也是我們現在可以測試並確保相容性的另一種多樣化啟動情況。我們支援的每個 Linux/x86 和 Linux/arm64 啟動通訊協定變化版本，都會讓日後在其他板子上使用原始韌體時，更有可能順利啟動，並且更接近開箱即用的體驗。同樣地，對於長期的「一般 x86 電腦」案例，這也是最有可能讓大眾廣泛採用新開放原始碼作業系統的載具。
未知
推出新模擬器時，會遇到許多未知因素，包括我們需要花費多少時間進行偵錯，以及如何解決目前未知的問題。我們發現的錯誤可能需要核心、驅動程式或其他團隊投入額外的工作 (先前未編列預算)，或者我們需要重新調整這項工作的優先順序。如果我們發現錯誤，就會優先處理相關群組。
既有技術與參考資料
不適用。