AMD IOMMU：打造高效I/O虚拟化“直通道”

从像VMware和Xen这样的虚拟管理器（VMM）看出，你可以在不借助硬件的情况下在x86上创建有效的虚拟机。但是解决x86的虚拟化制约问题带来了重要的软件开销——可以通过在较低水平上进行一些架构改造来避免这个开销。

AMD的AMD-V硬件虚拟化技术（AMD64扩展）通过提供一种超级权限操作模式为VMM铺下了第一个硬件基础，在这种模式下，VMM可以控制客户操作系统。

第二个基础就是对虚拟I/O的硬件支持。AMD在今年二月发布了一项I/O虚拟化规范，透露了一款名为IOMMU（I/O Memory Management Unit）的设备设计。这个设计的实施将成为2007年规划的支持芯片组的一部分。但这些都实现了以后，VMM将能够利用IOMMU硬件从运行在客户操作系统上的软件对物理设备的更快速、更直接以及更安全的访问。

现有的VMM必须使用模拟设备将来自客户操作系统的驱动程序路由到VMM。这样做是为了管理对共同内存空间的访问，并闲置对内核模式驱动程序的真实设备访问。AMD的IOMMU设计消除了这些限制，提供DMA地址转换、对设备读取和写入的权限检查。有了IOMMU，客户操作系统中一个未经修改的驱动程序可以直接访问它的目标设备，避免了通过VMM运行产生的开销以及设备模拟。

什么是IOMMU？

IOMMU是管理对系统内存的设备访问。它位于外围设备和主机之间，将来自设备请求的地址转换为系统内存地址，并检查每个接入的适当权限。

通常情况下，AMD IOMMU是被部署成HyperTransport或者PCI桥接设备的一部分。在高端系统中，CPU和I/O hub之间可能会有多个HyperTransport连接，这时候就需要多个IOMMU。

现有的AMD64设备已经包括了一个更有限的地址转译工具——GART (Graphics Address Remapping Table)，就在芯片上。片上GART用于现有系统的设备地址转译，有时候它本身就可以作为一个IOMMU（尤其是在讨论Linux内核的时候），这导致了人们对现有GART和新IOMMU规范之间的混淆。

GART最初是设计允许图形芯片直接从系统内存读取结构特征，使用地址转译将系统中的配置收集到一个临近的域中，这个域被映射到一个图形设备可以“看”到的地址。但是GART也被Linux内核程序员用来让传统32位PCI设备能够访问可寻址范围之外的系统内存区域。这是通过编程让设备能够在受GART控制的显存区域内工作、然后使用GART将这个地址转换为真实的目标地址（4GB以上）来实现的。

新的IOMMU也可以做到这一旦，只是不受GART的限制（毕竟它不是针对这个用途设计的）。虽然GART在显存范围内是受限的，但IOMMU可以将设备显示的任何地址转换为一个系统地址。

更重要的是，IOMMU提供了一种保护机制，即限制设备对内存的访问，而GART只执行转译。正是地址转译和访问保护的结合让IOMMU对虚拟化具有重要价值。

转译和保护

有了IOMMU，每个设备可以分配到一个保护域。这个保护域定义了I/O页的转译将被用于域中的每个设备，并且明确了每个I/O页的读取权限。对于虚拟化来说，VMM可以指定所有设备分配到相同保护域中的一个特定客户操作系统，这将创建一系列为运行在特定客户操作系统中运行所有设备使用的地址转译和访问限制。

IOMMU将页转译缓存在一个TLB（Translation Lookaside Buffer）中。你需要键入保护域和设备请求地址才能进入TLB。因为保护域是缓存密钥的一部分，所以域中的所有设备共享TLB中的缓存地址。

IOMMU决定一台设备属于哪个保护域，然后使用这个域和设备请求地址查看TLB。TLB入口包括读写权限标记以及用于转译的目标系统地址，因此如果缓存中出现一个登入的话，许可标记将被用于决定是否允许该访问。

对于不在缓存中的地址来说（针对特定域），IOMMU会继续查看设备相关的I/O页表格。I/O页表格入口也包括连接到系统地址的许可信息。

因此，所有地址转译最重要么是一次成功的查看，这种情况下，适当的权限标记会告诉IOMMU允许还是阻隔访问，要么最终是一次失败的查看。然后，VMM使用IOMMU能够控制哪些系统页对每个设备（或者保护域中的设备组）是可见的，并明确指定每个域中每个页的读写访问权限。这些是通过控制IOMMU用来查看地址的I/O页表格实现的。

IOMMU提供的转译和保护双重功能提供了一种完全从用户代码、无需内核模式驱动程序操作设备的方式。IOMMU可以被用于限制用户流程分配的内存设备DMA，而不是使用可靠驱动程序控制对系统内存的访问。设备内存访问仍然是受特权代码保护的，但它是创建I/O页表格（而不是驱动程序）的特权代码。

中断处理程序仍需要在内核模式下运行。利用IOMMU的一种方式是创建一个有限制的、包括中断处理程序的内核模式驱动程序，或者从用户代码控制设备。

直接访问

IOMMU通过允许VMM直接将真实设备分配到客户操作系统让I/O虚拟化更有效。VMM无法模拟IOMMU的转译和保护功能，因为VMM是不能介于运行在客户操作系统上的内核模式驱动程序与底层硬件之间。因此，当缺少IOMMU的时候，VMM会取而代之作为客户操作系统的模拟设备。最后VMM将客户请求转换到运行主机操作系统或者hypervisor的真实驱动程序请求。

有了IOMMU，VMM会创建I/O页表格将系统物理地址映射到客户物理地址，为客户操作系统创建一个保护域，然后让客户操作系统入常运转。针对真实设备编写的驱动程序则作为那些未经修改、对底层转译无感知的客户操作系统的一部分而运行。客户I/O交易通过IOMMU的I/O映射被从其他客户独立出来。

IOMMU不支持系统内存需求页，之所以不能是因为外围设备不能被告知重试操作，这个操作要求处理页加载。向那些显示的页面进行的DMA传输可能失败，因此VMM不知道哪个页是DMA目标，锁定内存中的整个客户要求VMM通过IOMM支持外围设备。

显然，AMD的IOMMU在I/O设备虚拟化开销方面有着很大不同：避免设备模拟、取消转译层和允许本机驱动程序直接配合设备。我们很期待VMM在支持这项技术之后将获得怎样的性能结果。