T-Head原型為虛擬IOMMU提供創(chuàng)新的硬件支持

最近，T-Head 完成了基于 QEMU 的虛擬機虛擬 IOMMU 硬件支持的概念驗證，基于 T-Head IOMMU 提案中的規(guī)范在其成立時提交給 IOMMU TG 作為其中之一候選人提案。 T-Head IOMMU 的虛擬 IOMMU 設計展示了一種向虛擬機公開與主機使用的虛擬 IOMMU 相同的虛擬 IOMMU 的方法。好處是來賓虛擬機可以直接重新使用完全相同的內核驅動程序，并且消除了傳統(tǒng)解決方案中昂貴的基于軟件的仿真。

背景

出于性能或安全等原因，可以將物理 I/O 設備配置為由來賓虛擬機直接訪問，這種技術被廣泛稱為設備直通。直通設備受 IOMMU 轉換表的限制，因此它們只能對屬于它們所分配到的虛擬機的內存區(qū)域執(zhí)行 DMA。從虛擬機的角度來看，直通設備表現為直接訪問虛擬機物理地址空間的外圍設備。如果不合并 IOMMU 供虛擬機使用，虛擬機會遇到與主機中的所有設備都不由 IOMMU 管理的情況相同的不便和缺點。它們不能被進一步分配到虛擬機的用戶空間，也不能出于可靠性目的限制它們。

圖 1：模擬虛擬 IOMMU

如圖 1 所示，為虛擬機提供 IOMMU 的傳統(tǒng)解決方案是 trap-n-emulate 或半虛擬化。 Trap-n-emulate 很昂貴。雖然它向來賓虛擬機提供與主機使用的硬件 IOMMU 相同的 IOMMU，但是，來賓對虛擬 IOMMU 的訪問會觸發(fā)由主機處理的異常。處理是昂貴的。主機不僅需要模擬對虛擬 IOMMU 寄存器的訪問，還需要在虛擬機修改其內存駐留翻譯結構時將翻譯的兩個階段結合起來。后者是由于現有的硬件 IOMMU 不直接使用 guest 的轉換表，因為硬件只支持一個階段的地址轉換。一些 IOMMU，例如 ARM SMMU v3，可以進行嵌套地址轉換，也有內核補丁可以直接使用guest的轉換表，但是補丁仍然是RFC，估計是硬件架構定義的表結構導致軟件交互復雜。

圖 2：半虛擬化 IOMMU

半虛擬化（如圖 2 所示）通過要求來賓虛擬機將其 IOMMU 配置顯式傳達給主機來減少仿真工作。最大的缺點是需要修改來賓和主機，因此，在某些環(huán)境中可能不可用。

T-Head 對虛擬 IOMMU 的硬件支持

T-Head的IOMMU提案試圖從硬件架構開始解決上述缺點。簡要的想法是指定一個內存區(qū)域（稱為狀態(tài)區(qū)域），用于呈現給來賓虛擬機的虛擬 IOMMU 的寄存器狀態(tài)。同時，主機的表結構包括指向狀態(tài)區(qū)域的指針。當需要轉換 DMA 請求時，IOMMU 會查找狀態(tài)區(qū)域，從中獲取轉換表和來賓虛擬機配置的虛擬 IOMMU 的狀態(tài)。隨后，硬件 IOMMU 以與主機結構相同的方式遍歷來賓的表結構，將所有地址視為來賓物理地址，即以嵌套轉換方式。

圖 3：T 頭的硬件輔助虛擬 IOMMU

T-Head 的虛擬 IOMMU（如圖 3 所示）避免了昂貴的仿真，因為客戶機的配置直接由硬件使用。也就是說，來賓正在與硬件支持的“直通”IOMMU 進行交互。IOMMU 的接口由硬件 IOMMU 直接公開;它與主機的 IOMMU 相同。主機使用的完全相同的驅動程序可以直接重復使用。使用內存來存儲虛擬 IOMMU 的階段使解決方案具有可擴展性，而不受寄存器上的資源約束。

原型

我們已經完成了QEMU和Linux/KVM的概念驗證。我們在本機 QEMU 中的 IOMMU 仿真代碼中添加了對根據 T-Head 的 IOMMU 規(guī)范的嵌套轉換的支持。我們以以前的設備直通工作為基礎，在 RISC-V QEMU 中向 VFIO 層添加了嵌套的 IOMMU 支持。IOMMU 內核驅動程序為 RISC-V QEMU 公開了一個新的 API，用于管理狀態(tài)區(qū)域并在轉換描述符中配置設備 ID，新 API 作為名為 /dev/xt_iommu 的設備文件存在，我們覆蓋了該文件上的 mmap 和寫入處理程序。

未來工作

我們將繼續(xù)評估和改進當前的原型和設計，包括在 RTL 中實現它。在適當的時候，我們希望將此解決方案貢獻給更大的RISC-V社區(qū)。

審核編輯：湯梓紅