IOMMU 5313181 207399230 2008-04-22T17:16:17Z Kubanczyk 1401217 Quick-adding category "Computer peripherals" (using [[WP:HOTCAT|HotCat]]) [[Image:MMU and IOMMU.svg|thumb|282px|right|Comparison of the I/O memory management unit ('''IOMMU''') to the [[memory management unit]] ('''MMU''').]] In [[computing]], an '''input/output memory management unit''' ('''IOMMU''') is a [[memory management unit]] (MMU) that connects a [[direct memory access|DMA]]-capable I/O [[computer bus|bus]] to the [[main memory]]. Like a traditional MMU, that translates [[central processing unit|CPU]]-visible [[virtual address]]es to [[physical address]]es, the IOMMU takes care of mapping device-visible virtual addresses (also called ''device addresses'' or ''I/O addresses'' in this context) to physical addresses. Some units also provide [[memory protection]] from misbehaving devices. An example IOMMU is the [[Graphics Address Remapping Table]] (GART) used by [[Accelerated Graphics Port|AGP]] and [[PCI Express]] graphics cards. [[AMD]] has published a specification for IOMMU technology in the HyperTransport architecture<ref>{{cite web |title=AMD I/O Virtualization Technology (IOMMU) Specification Revision 1.0 |url=http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/34434.pdf |accessdate=2006-02-01}}</ref>. [[Intel]] has published a specification for IOMMU technology as Virtualization Technology for Directed I/O, abbreviated VT-d.<ref>{{cite web |title=Mainstreaming Server Virtualization: The Intel Approach |url=http://www.intel.com/business/technologies/idc_virtualization_wp.pdf |accessdate=2006-03-01}}</ref> Information about the Sun IOMMU has been published in the Device Virtual Memory Access (DVMA) section of the Solaris Developer Connection.<ref>{{cite web |title=DVMA Resources and IOMMU Translations |url=http://developers.sun.com/solaris/developer/support/driver/wps/pci/html/DMA.doc.html#289 |accessdate=2007-04-30}}</ref> The [[IBM]] [[Translation Control Entry]] (TCE) has been described in a document entitled Logical Partition Security in the IBM [[eServer]] [[pSeries]] 690.<ref>{{cite web |title=Logical Partition Security in the IBM eServer pSeries 690 |url=http://www-03.ibm.com/servers/eserver/pseries/hardware/whitepapers/lpar_security.html |accessdate=2007-04-30}}</ref> The PCI-SIG has relevant work under the terms I/O Virtualization (IOV)<ref>{{cite web |title=I/O Virtualization specifications |url=http://www.pcisig.com/specifications/iov/ |accessdate=2007-05-01}}</ref> and Address Translation Services (ATS). == Advantages == The advantages of having an IOMMU, compared to direct physical addressing of the memory, include: * Large regions of memory can be allocated without the need to be contiguous in physical memory &mdash; the IOMMU will take care of mapping contiguous virtual addresses to the underlying fragmented physical addresses. Thus, the use of [[vectored I/O]] ([[scatter-gather]] lists) can sometimes be avoided. * For devices that do not support memory addresses long enough to address the entire physical memory, the device can still address the entire memory through the IOMMU. This avoids overhead associated with copying buffers to and from the memory space the peripheral can address. ** For example, on contemporary x86 computers, more than 4 GiB of memory can be used, enabled by the [[Physical Address Extension|PAE]] feature in an x86 processor. Still, an ordinary 32-bit PCI device simply cannot address the memory above the 4 GiB boundary, and thus it cannot perform DMA to it. Without an IOMMU, the operating system is forced to implement time consuming [[double buffer]]s<ref>{{cite web|url=http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx#E2D|title=Physical Address Extension - PAE Memory and Windows|publisher=Microsoft Windows Hardware Development Central|date=2005|accessdate=2008-04-07}}</ref> (Windows nomenclature) also known as [[bounce buffer]]s (Linux). * [[Memory protection]] from malicious or misbehaving devices: a device cannot read or write to memory that hasn't been explicitly allocated (mapped) for it. The memory protection is based on the fact that OS running on the CPU (see figure) exclusively controls both the MMU and the IOMMU. The devices are physically unable to circumvent or corrupt configured memory management tables. ** With [[virtualization]], ''guest'' operating systems can use hardware that is not specifically made for virtualization. Higher performance hardware such as graphics cards use [[DMA]] to access memory directly; in a virtual environment all the memory addresses are remapped by the virtual machine software, which causes DMA devices to fail. The IOMMU handles this remapping, allowing for the native device drivers to be used in a guest operating system. * In some architectures IOMMU performs also [[hardware interrupt]] remapping, in a manner similar to standard memory address remapping. * Peripheral memory paging can be supported by an IOMMU. A peripheral using the PCI-SIG PCIe Address Translation Services (ATS) Page Request Interface (PRI) extension can detect and signal the need for memory manager services. For system architectures in which port I/O is a distinct address space from the memory address space, an IOMMU is not used when the CPU communicates with devices via [[I/O port]]s. In system architectures in which port I/O and memory are mapped into a suitable address space, an IOMMU can translate port I/O accesses. == Disadvantages == The disadvantages of having an IOMMU, compared to direct physical addressing of the memory, include:<ref name=price-of-safety>{{cite conference |author=Muli Ben-Yehuda, Jimi Xenidis, Michal Ostrowski |date=[[2007-06-27]] |title=Price of Safety: Evaluating IOMMU Performance |publisher=[[IBM Research]] |format=PDF |booktitle=Proceedings of the Linux Symposium 2007 |location=Ottawa, Ontario, Canada |url=https://ols2006.108.redhat.com/2007/Reprints/ben-yehuda-Reprint.pdf |accessdate=2007-07-02 }}</ref> * Some degradation of performance from translation and management overhead (e.g., page table walks). * Consumption of physical memory for the added I/O [[page table|page (translation) table]]s. This can be mitigated if the tables can be shared with the processor. == IOMMU in relation to virtualization == When an operating system is running inside a [[virtual machine]], including systems that use [[paravirtualization]], such as [[Xen (virtual machine monitor)|Xen]], it does not usually know the physical addresses of memory that it accesses. This makes providing direct access to the computer hardware difficult, because if the OS tried to instruct the hardware to perform a [[direct memory access]] (DMA), it would likely corrupt the memory, as the hardware does not know about the mapping between the virtual real addresses used by the virtualized guest system. The corruption is avoided because the hypervisor or OS intervenes in the I/O operation to apply the translations; unfortunately, this delays the I/O operation. An IOMMU can solve this problem by re-mapping the addresses accessed by the hardware according to the same (or a compatible) translation table used by the virtual machine guest.<ref>{{cite web |title=Xen FAQ: In DomU, how can I use 3D graphics |url=http://wiki.xensource.com/xenwiki/XenFaq#head-d5a7a247a5168517291228a6f02fd74b419badeb |accessdate=2006-12-12}}</ref> == See also == * [[Virtual memory]] * [[Memory-mapped I/O]] * [[Direct memory access]] == References == # {{cite journal |first=James |last=Bottomley |title=Using DMA |journal=[[Linux Journal]] |date=2004-05-01 |publisher=[[Specialized Systems Consultants]] |url=http://www.linuxjournal.com/node/7104/print }} <references/> [[Category:Computer memory]] [[Category:Computer architecture]] [[Category:Computer peripherals]] [[de:IOMMU]] [[ja:IOMMU]]