输入输出内存管理单元

在计算机领域，输入输出内存管理单元（英語：，缩写IOMMU）是一种内存管理单元（MMU），它将具有直接記憶體存取能力（可以DMA）的I/O总线连接至主内存。如传统的MMU（将CPU可见的虚拟地址转换为物理地址）一样，IOMMU将设备可见的虚拟地址（在此上下文中也称设备地址或I/O地址）映射到物理地址。部分单元还提供内存保护功能，防止故障或恶意的设备。

输入输出内存管理单元（IOMMU）与内存管理单元（MMU）的比较。

IOMMU的一个例子是Intel架构和AMD计算机上使用的AGP和PCI Express显卡所使用的图形地址映射表（GART）。

在x86架构将CPU与平台路徑控制器（PCH）的北桥和南桥拆分前，I/O虚拟化不是由CPU而是由芯片组执行。[1][2]

优点

与内存的直接物理寻址相比，拥有IOMMU的优势包括：

  • 分配大容量内存区域可以不需连续的物理内存——IOMMU可将连续的虚拟地址映射到底层中分段的物理地址。因此，有时可以避免使用向量化I/O（分散-集中列表）。
  • 不支持寻址整个物理内存长度的设备仍可通过IOMMU访问整个内存，避免了与外围设备的可寻址内存空间复制缓冲区有关的开销。
    • 例如，x86计算机可以用x86处理器中的物理地址扩展（PAE）功能访问超过4GB的内存。但是，普通的32位PCI设备根本无法访问4Gib范围外的内存，并且因此它不能直接访问。如果没有IOMMU，操作系统将不得不实现耗时的反弹缓冲区（也称双缓冲区[3]。）
  • 内存得到保护，尝试进行DMA攻击的恶意设备或尝试传输错误内存的故障设备无权读写非明确分配（映射）的内存。内存保护基于一项事实，CPU上运行的操作系统（见图例）专门控制MMU和IOMMU。设备本身无法绕过或损坏已配置的内存管理表。
    • 在虚拟化中，客户机操作系统可以使用非专为虚拟化设计的硬件。诸如使用DMA直接访问内存的显卡等硬件会有更高性能。在虚拟环境中，所有内存地址都会被虚拟机软件重映射，从而导致DMA设备遇到故障。IOMMU则处理这种重映射，允许在客户机操作系统中使用原生的设备驱动程序。
  • 在某些架构中，IOMMU也执行硬件中断重映射，工作方式类似标准内存地址重映射。
  • 外设内存分页可由IOMMU支持。使用PCI-SIG PCIe地址转换服务（ATS）分页请求接口（PRI）扩展的外设可以检测和表示需要内存管理服务。

对于端口I/O的地址空间与内存的内存地址空间不同的系统架构，CPU与设备通过I/O端口通信时不使用。如果端口I/O与内存的地址空间被映射到一个合适的空间，则可以用IOMMU转换I/O访问。

缺点

与内存的直接物理寻址相比，IOMMU的缺点包括：[4]

  • 性能因翻译和管理开销（例如页表变动）有所下降。
  • 增加的I/O分頁表（转换表）消耗一些物理内存。如果该表可与处理器共享，则此问题可以缓解。

虚拟化

当操作系统在虛擬機器内运行时（包括使用半虚拟化的系统，例如Xen），其通常不知道它要访问的内存的主机物理地址。这使其难以直接访问计算机硬件，因为如果客户机系统尝试用客户机的物理地址进行直接記憶體存取（DMA）来吩咐硬件，其可能损坏内存数据，因为硬件不知道给定虚拟机客户机物理地址与主机物理地址之间的映射关系。而由管理程序或主机操作系统介入I/O操作来应用翻译则可以避免损坏，但会增加此I/O操作的延迟。

IOMMU可以依靠将客户机物理地址映射到主机物理地址的相同或兼容转换表重映射硬件访问地址，从而解决延迟问题。[5]

Intel和AMD的IOMMU虛擬化需要晶片組和CPU支援IOMMU虛擬化。Intel的IOMMU虛擬化稱為VT-d。

已公布规范
  • AMD已出版一份IOMMU技术规范。[6][7]
  • 英特尔已出版一份针对虚拟化技术直接I/O的IOMMU技术规范，简称为VT-d。[8]
  • 有关昇陽電腦（Sun）IOMMU的信息已在Solaris Developer Connection的设备虚拟内存访问（DVMA）部分发布。[9]
  • IBM Translation Control Entry (TCE) 在eServer pSeries 690中标题为“逻辑分区安全”的文档中进行了描述。[10]
  • PCI-SIG对I/O虚拟化（IOV）[11]和地址转换服务（ATS）有相关工作。
  • ARM将其IOMMU版本定义为系统内存管理单元（SMMU）[12]，以补充其虚拟化架构。[13]

参见

参考资料
  1. . intel.com. 2006-08-10 [2014-06-07]. （原始内容存档于2007-01-20）.
  2. . intel.com. 2014-02-14 [2014-06-07]. （原始内容存档于2015-12-22）.
  3. . Microsoft Windows Hardware Development Central. 2005 [2008-04-07]. （原始内容存档于2008-04-06）.
  4. Muli Ben-Yehuda; Jimi Xenidis; Michal Ostrowski. (PDF). . Ottawa, Ontario, Canada: IBM Research. 2007-06-27 [2013-02-28]. （原始内容 (PDF)存档于2020-12-18）.
  5. . [2006-12-12]. （原始内容存档于2008-10-02）.
  6. (PDF). amd.com. 2011-03-24 [2014-01-11]. （原始内容 (PDF)存档于2021-02-25）.
  7. (PDF). amd.com. 2015-03-02 [2016-01-05]. （原始内容 (PDF)存档于2018-06-16）.
  8. (PDF). [2016-02-17]. （原始内容 (PDF)存档于2020-08-24）.
  9. . [2007-04-30]. （原始内容存档于2012-04-19）.
  10. . [2007-04-30]. （原始内容存档于2007-03-10）.
  11. . [2007-05-01]. （原始内容存档于2021-03-08）.
  12. . [2013-05-13]. （原始内容存档于2016-09-23）.
  13. . [2013-05-13]. （原始内容存档于2013-05-03）.

外部链接
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.