T-Head原型为虚拟IOMMU提供创新的硬件支持

最近，T-Head 完成了基于 QEMU 的虚拟机虚拟 IOMMU 硬件支持的概念验证，基于 T-Head IOMMU 提案中的规范在其成立时提交给 IOMMU TG 作为其中之一候选人提案。 T-Head IOMMU 的虚拟 IOMMU 设计展示了一种向虚拟机公开与主机使用的虚拟 IOMMU 相同的虚拟 IOMMU 的方法。好处是来宾虚拟机可以直接重新使用完全相同的内核驱动程序，并且消除了传统解决方案中昂贵的基于软件的仿真。

背景

出于性能或安全等原因，可以将物理 I/O 设备配置为由来宾虚拟机直接访问，这种技术被广泛称为设备直通。直通设备受 IOMMU 转换表的限制，因此它们只能对属于它们所分配到的虚拟机的内存区域执行 DMA。从虚拟机的角度来看，直通设备表现为直接访问虚拟机物理地址空间的外围设备。如果不合并 IOMMU 供虚拟机使用，虚拟机会遇到与主机中的所有设备都不由 IOMMU 管理的情况相同的不便和缺点。它们不能被进一步分配到虚拟机的用户空间，也不能出于可靠性目的限制它们。

图 1：模拟虚拟 IOMMU

如图 1 所示，为虚拟机提供 IOMMU 的传统解决方案是 trap-n-emulate 或半虚拟化。 Trap-n-emulate 很昂贵。虽然它向来宾虚拟机提供与主机使用的硬件 IOMMU 相同的 IOMMU，但是，来宾对虚拟 IOMMU 的访问会触发由主机处理的异常。处理是昂贵的。主机不仅需要模拟对虚拟 IOMMU 寄存器的访问，还需要在虚拟机修改其内存驻留翻译结构时将翻译的两个阶段结合起来。后者是由于现有的硬件 IOMMU 不直接使用 guest 的转换表，因为硬件只支持一个阶段的地址转换。一些 IOMMU，例如 ARM SMMU v3，可以进行嵌套地址转换，也有内核补丁可以直接使用guest的转换表，但是补丁仍然是RFC，估计是硬件架构定义的表结构导致软件交互复杂。

图 2：半虚拟化 IOMMU

半虚拟化（如图 2 所示）通过要求来宾虚拟机将其 IOMMU 配置显式传达给主机来减少仿真工作。最大的缺点是需要修改来宾和主机，因此，在某些环境中可能不可用。

T-Head 对虚拟 IOMMU 的硬件支持

T-Head的IOMMU提案试图从硬件架构开始解决上述缺点。简要的想法是指定一个内存区域（称为状态区域），用于呈现给来宾虚拟机的虚拟 IOMMU 的寄存器状态。同时，主机的表结构包括指向状态区域的指针。当需要转换 DMA 请求时，IOMMU 会查找状态区域，从中获取转换表和来宾虚拟机配置的虚拟 IOMMU 的状态。随后，硬件 IOMMU 以与主机结构相同的方式遍历来宾的表结构，将所有地址视为来宾物理地址，即以嵌套转换方式。

图 3：T 头的硬件辅助虚拟 IOMMU

T-Head 的虚拟 IOMMU（如图 3 所示）避免了昂贵的仿真，因为客户机的配置直接由硬件使用。也就是说，来宾正在与硬件支持的“直通”IOMMU 进行交互。IOMMU 的接口由硬件 IOMMU 直接公开;它与主机的 IOMMU 相同。主机使用的完全相同的驱动程序可以直接重复使用。使用内存来存储虚拟 IOMMU 的阶段使解决方案具有可扩展性，而不受寄存器上的资源约束。

原型

我们已经完成了QEMU和Linux/KVM的概念验证。我们在本机 QEMU 中的 IOMMU 仿真代码中添加了对根据 T-Head 的 IOMMU 规范的嵌套转换的支持。我们以以前的设备直通工作为基础，在 RISC-V QEMU 中向 VFIO 层添加了嵌套的 IOMMU 支持。IOMMU 内核驱动程序为 RISC-V QEMU 公开了一个新的 API，用于管理状态区域并在转换描述符中配置设备 ID，新 API 作为名为 /dev/xt_iommu 的设备文件存在，我们覆盖了该文件上的 mmap 和写入处理程序。

未来工作

我们将继续评估和改进当前的原型和设计，包括在 RTL 中实现它。在适当的时候，我们希望将此解决方案贡献给更大的RISC-V社区。

　　审核编辑：汤梓红