近距離了解 VirtIO 和 GPU 虛擬化

這是一篇 Linaro 開發團隊項目組的科普文章。我們在處理器虛擬化項目中，經常會遇到 VirtIO 相關的問題；比如運行 Andriod 系統的時候需要運行 VirtIO 組件。‍‍‍隨著 Cassini 項目和 SOAFEE（嵌入式邊緣可擴展開放架構）等項目的開發，VirtIO 成爲支持基于標准的雲原生邊緣開發/部署環境的關鍵構件，旨在實現這些高效的 EDGE 開發環境。GPU 虛擬化是 VirtIO 中較爲複雜的組件之一。

本文將討論其中的一些挑戰以及 Linaro 開發團隊在這一領域取得的進展。基于VirtIO的塊和網絡設備是相對簡單的抽象，可以很好地映射到底層硬件。這些設備經過多輪優化，最大限度地減少了虛擬化開銷。由于硬件種類繁多，圖形處理器（GPU）更難抽象化。在簡單的 2D 圖形時代，任何特定的硬件都只能支持特定範圍的內存布局和色深。隨著技術的發展，圖形引擎獲得了複制內存區域、管理精靈或旋轉紋理等各種不同的能力。隨著 3D 技術的出現，情況並沒有變得更簡單。

現代 GPU 實際上是一種特殊用途處理器，經過優化後可以執行渲染現代場景所需的大量並行計算。很多現代超級計算機都以這些數字運算流水線爲核心，這並不奇怪。然而，與大多數 CPU 不同的是，GPU 執行模型的細節往往不爲用戶所知。通常情況下，GPU 要麽使用更高級別的 API 進行編程，然後由專有的二進制 Blob 將其翻譯成秘密的隱藏指令流，再輸送到 GPU。雖然有許多開放的 GPU 編程 API，旨在實現 GPU 之間的可移植性，但也有與特定硬件綁定的供應商專用庫。所有這些都使得 GPU 虛擬化成爲一個特別具有挑戰性的領域。可以使用的方法大致有兩種：虛擬函數和 API 轉發。

虛擬功能

這種方法與其他高性能虛擬化硬件的做法類似，都是將單個物理卡劃分爲多個虛擬功能（VF）。然後，每個 VF 都可以與訪客共享，訪客可以直接驅動它，就像作爲主機運行一樣。在服務器領域，主要 GPU 廠商（英特爾、AMD、nVidia）的高端 GPU 卡都支持 SR-IOV。它使用成熟的 PCI 分區在客戶機之間劃分 VF。然而，面向汽車和工業市場的 GPU 面臨兩個挑戰：

- VF 數量較少（可能只有 2 個，需要抽象化）- 平台特定的分區方案市場上支持 VF 分區的 GPU 仍然相當罕見，而且現有的 GPU 通常只支持有限的分割，這意味著仍然需要一個完全抽象的虛擬 GPU 來複用多個有圖形需求的客戶。由于這些設備通常是平台設備（即直接映射內存，而非 PCI 設備），因此需要在固件、平台和驅動程序之間協調，才能支持這些 VF 的分配。從簡潔抽象的角度來看，這使得問題變得更加複雜。

軟件輔助虛擬功能爲了解決這些限制，我們采用了各種軟件輔助方法來彌補純硬件支持的不足。其最初形式是一種名爲 "中介設備"（mdev）的擴展，在硬件允許的情況下，它允許主機內核對設備進行分區。目前，支持該功能的內核驅動程序只有英特爾 i915 驅動程序和一個 s390 加密驅動程序。

利用 virtIO-gpu 的擴展（本地上下文）優化 GPU 虛擬化。

此方法：

- 利用 VirtIO 機制實現常用功能

- 直接向客戶機提供原生上下文

- 客戶機運行經過修改的原生 GPU 驅動程序，支持：

- VirtIO 感知

- 針對特定 GPU 的自定義協議

應用程序接口轉發GPU 虛擬化的另一種方法是 API 轉發。它的工作原理是爲客戶提供一個理想化的虛擬硬件，該硬件與共享庫抽象的要求密切相關。VirtIO GPU 最初的 3D 加速基于 OpenGL。

該設備提供了一個名爲 VirGL 的虛擬 OpenGL 設備，它基于 Gallium3D 接口。這樣，訪客只需向設備輸入一系列 OpenGL 命令和通用的獨立于 GPU 的著色器中間語言。在後端，這些命令被輸入 virglrenderer，然後通過主機 GPU 進行渲染。對 VirGL 方法的主要不滿在于效率。雖然可以運行流暢的桌面體驗，但性能卻遠低于直接在主機上運行的預期。其中一個原因可能是古老的 OpenGl 編程模型與現代 GPU 的編程方式相比過于抽象。再加上不可避免的虛擬化開銷，加劇了其性能問題。爲了取代 OpenGL，我們開發了一種名爲 Vulkan 的更現代的 API，它是一種更低級的編程 API，更貼近現代圖形硬件的工作方式。它還將圖形與計算工作流（GPUS 的一個重要用例）統一在一個 API 下。

雖然虛擬 GPU 對 Vulkan 的支持尚未在 QEMU 等項目中實現，但一些替代虛擬機監控器（VMM）能夠使用這種模式提供更高效的虛擬 GPU 實現。最後還有第三種協議，即 Wayland 協議，它並不直接針對 GPU，而是用于與支持 3D 的顯示服務器進行對話。這樣，在客戶機中運行的客戶程序就能與主機顯示管理器無縫集成。最初的用例是讓 CrosVM 客戶端中的 Linux 應用程序與 ChromeOS 主機集成。有趣的是，該協議還針對車載娛樂系統進行了擴展。

兩種方法的比較對于那些希望通過保持盡可能輕量級的抽象來盡可能提高圖形硬件性能的用戶來說，虛擬函數似乎是未來的發展方向。此外，通過將複雜的圖形棧隔離在客戶域庫中，還可以降低開發風險，這也是一個很好的安全論據。GPU 就其本質而言，必須處理大量不受信任的訪客數據。

不過，這種直通方法也有一些缺點。在雲原生開發中，最大的問題是將客戶代碼綁定到特定的 GPU 架構上，這意味著雲和邊緣部署之間的可移植性較差。此外，對于 Linaro 這家主要使用開源技術的公司來說，增加支持需要訪問遍布整個堆棧的專有代碼，而不是處理開源抽象。我們認爲，通過使用 Rust 等更安全的語言編寫 VirtIO 後端，圖形堆棧的一些安全問題可以得到改善。 但需要注意的是，大部分後端最終仍將使用普通 C 語言庫進行處理。要降低特權主機被攻擊的風險，一種方法是將圖形後端轉移到單獨的虛擬機（有時稱爲驅動域）中。這樣，如果守護進程被攻破，攻擊者仍會被控制在一個相對有限的環境中。

與 Orko 項目的關系

Orko 項目是我們之前的虛擬化項目 Stratos 的精神繼承者。我們正在努力將一些 VirtIO 設備集成到 SOAFEE 參考平台中，以加快其應用。多媒體是汽車工作負載的主要驅動力，因此擁有一個實用的 GPU 解決方案非常重要。最初有兩項工作計劃用于支持 GPU。

衡量抽象成本

雖然有一些關于 VirGL 在某些系統上的性能的轶事，但我們還沒有看到對這些抽象在 ARM 硬件上的成本進行全面測量。我們想知道這些較新的圖形管線是否可用于處理像運行 AAA 級遊戲一樣的繁重工作負載，而不會産生過多的開銷。

對于 QEMU，有幾個小組提出了各種補丁，通過各種擴展來增強 virtio-gpu 設備。我們打算在幫助審查的同時，將這些補丁與 QEMU 最近的 xenpvh 支持集成，並開始在實際硬件上測量每個抽象的成本。我們還想探索使用 CrosVM Wayland 後端（它在引擎蓋下使用 vhost-user），看看與 QEMU 的 xenpvh 模式和我們的 Xen vhost-user 前端集成有多少工作量。

獨立的 virtio-gpu 守護進程

雖然我們在 SOAFEE 平台中使用 QEMU 來幫助啓動 VirtIO 設備，但我們的願景仍然是利用 rust-vmm 組件，使用 Rust 編寫獨立于管理程序的獨立守護進程。獨立守護進程之所以有用，還有很多其他原因：

通過 rust-vmm 特質和 vhost-user 擴展，我們隱藏了 Xen 中映射內存和通知的底層實現，實現了跨管理程序的抽象層。這種方法簡化了管理程序的交互，並提高了虛擬機管理的靈活性。如果沒有獨立于核心 VMM 的後端，我們就無法嘗試我之前討論過的驅動域概念

最好的辦法是擴展 CrosVM 的 Wayland 實現以支持其他 GPU 命令流，還是從頭開始編寫一個新的後端，還有待觀察。我們目前正在進行准備工作，測量各種抽象的開銷，以幫助我們了解未來的發展方向。

-對此，您有什麽看法見解？-

-歡迎在評論區留言探討和分享。-