| RFC-0249：平台支援 crosvm | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這項 RFC 建議除了 qemu 和 femu 之外，crosvm 也應成為 Fuchsia 平台支援的頂尖模擬器。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-04-24 |
| 審查日期 (年-月-日) | 2024-05-31 |
摘要
本文件建議 Fuchsia 專案將 crosvm 新增為支援的系統設定。這可讓我們在 crosvm 上持續測試 Fuchsia，並確保 crosvm 在 ToT 保持運作。
提振精神
根據官方文件，crosvm 是代管 (又稱第 2 類) 虛擬機器監控器，類似於 QEMU-KVM 或 VirtualBox。這項工具支援多種架構，包括 x86_64 和 arm64，以及多個硬體加速後端，包括 Linux KVM。
目前已有 Fuchsia 使用者在以 crosvm 為基礎的模擬器中使用 Fuchsia，我們預期未來會有更多使用者。透過 crosvm 支援，我們將能針對這些硬體的 crosvm 實作項目測試多個驅動程式。雖然我們已支援 QEMU、FEMU、machina 和 GCE，可實作各種虛擬化裝置，但每種實作方式都有其特殊之處，在其中一種模擬器環境中運作的軟體，不一定能在其他環境中運作。為確保不會中斷 crosvm 使用者的作業，我們需要在 Fuchsia 的測試基礎架構中，針對 crosvm 啟用 Fuchsia 的自動測試。
此外，crosvm 支援部分裝置，但其他模擬環境尚未支援。
此外，我們也需要讓驅動程式庫開發人員更輕鬆地編寫及維護用於 crosvm 環境的驅動程式。目前這項作業需要在樹狀結構外的產品導向環境中執行 Fuchsia。這種做法無法擴充。
最後，部分技術 (例如 x86 的 64 位元 Linux 開機通訊協定) 不受任何現有硬體目標支援。因此我們尚未實作支援這類功能的 Linux 開機墊片，因為無法測試。
利害關係人
協助人員：
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 預先建構項目，並新增啟動 crosvm 的 ffx 支援功能，最後設定相關機器人，在提交前和/或後執行，藉此將 crosvm 支援功能新增至平台。
實作
啟動和 64 位元 Linux 啟動墊片
為了啟動 crosvm 的支援功能，我們需要先讓 Fuchsia 在 crosvm 上啟動。crosvm 目前僅支援提供自訂啟動載入程式或 64 位元 Linux 啟動通訊協定。Fuchsia 目前支援提供以 EFI 為基礎的系統啟動載入程式，以及多重啟動和 32 位元 Linux 啟動通訊協定。這組不相交的開機選項會導致 Fuchsia 目前無法在 crosvm 上開機。因此，支援 crosvm 的第一步是進行 crosvm 的啟動活動，並為 64 位元啟動通訊協定實作另一個啟動墊片。
值得一提的是，這個問題只會出現在 x86 上。Fuchsia 會在 aarch64 下的 crosvm 上啟動。不過，由於 crosvm 預設只支援硬體加速虛擬化，一般 Fuchsia 開發人員很難在 aarch64 下的 crosvm 上實際執行 Fuchsia。我們已證明 crosvm 過去能夠使用 arm64 Linux 啟動墊片啟動 Fuchsia，但可能也需要額外作業，確保系統能持續啟動。
除了啟動墊片工作外，可能還需要針對相關儲存空間和網路驅動程式進行一些工作，確保裝置能與 ffx 和基礎架構搭配運作。完成 bootshim 工作後，我們就會揭露這項工作，這項工作很快就會在 x86_64 上推出。我們可能需要 crosvm 團隊的支援，才能在他們的程式碼中完成所有必要的修正。
crosvm 預先建構的滾動器
系統會設定新的建構工具，從上游的 crosvm 存放區提取最新來源、啟用相關功能並建構，然後將最終構件上傳至 CIPD。
負責人員會更新整合存放區，確保日後的 jiri update 指令會傳送更新後的 crosvm 二進位檔。
支援 crosvm 的 ffx emu，做為替代引擎
ffx emu start --engine 旗標會新增一個選項，啟用後即可選擇 crosvm，而非 qemu 或 femu。系統預設會向使用者顯示特定裝置組合，盡可能貼近 crosvm 的實際樹狀結構外使用情境。ffx emu由於 crosvm 有多位使用者，這可能表示我們需要支援多種裝置設定。
您可以選擇性地新增 fx crosvm 指令包裝函式，進一步簡化這個工作流程，但 fx run-boot-test --crosvm 中已提供部分支援。
CI/CQ 建構工具
平台能夠在 crosvm 上啟動 Fuchsia 後，我們就會推出建構工具，確保 crosvm 支援功能持續正常運作。
就我們的用途而言，由於 minimal.x64 產品/主機板組合適用於 crosvm，因此我們不需要其他建構工具，因為可以將用於 qemu 的建構工具重新用於這個用途。
這些建構工具一開始會是僅供參考的建構工具，但如果證明穩定性良好，我們就能將其更新為封鎖建構工具，這也是建立新封鎖建構工具的典型程序。
這些建構工具是在 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 提出要求，希望支援 Fuchsia。但最終來說，Fuchsia 的目標市場比其他主要作業系統小得多，因此要說服 crosvm 自行提供這類支援，實際上相當困難。
根據我們在供應商啟動韌體 (包括開放原始碼韌體，例如 CrOS depthcharge) 方面的經驗，要實作及維護穩固的 Fuchsia 專屬啟動支援功能，可能相當困難。
此外，這也不會為我們提供 crosvm 的 Linux 開機支援，因為這是另一種根深蒂固的開機情境，我們現在可以測試並確保相容性。我們支援的 Linux/x86 和 Linux/arm64 開機通訊協定變體越多，日後在其他主機板上使用原廠韌體啟動時，就越有可能順利完成，且越接近開箱即用狀態。長期而言，這對「一般 x86 電腦」也是如此，因為從歷史來看，這類電腦最有可能成為新開放原始碼作業系統普及的媒介。
不明
開發新模擬器時，會遇到許多未知情況，包括我們需要花費多少工程時間來偵錯，以及解決目前未知的問題。我們發現的錯誤可能需要核心、驅動程式或其他團隊投入額外工作 (先前未編列預算)，或是我們需要重新安排這項工作的優先順序。如果發現錯誤，我們會與相關群組共同決定優先順序。
既有技術和參考資料
不支援這項操作。