= Direct memory access
= DMA
{c}
{synonym}
<Direct memory access> transfers data between a device and <computer memory> without the <CPU> executing a copy instruction for each item. The <CPU> still sets up the operation and observes completion. <DMA> answers who moves the data; an <interrupt> answers how a need for attention is announced. A <DMA> transfer can therefore finish with <interrupt-driven input-output> or with <polled input-output>. https://pages.cs.wisc.edu/~remzi/OSTEP/file-devices.pdf[Arpaci-Dusseau and Arpaci-Dusseau, OSTEP chapter 36, section 36.5: DMA]{ref}
For a toy receive operation, the <CPU> arranges a four-<byte> <DMA buffer> and tells the device its <DMA address>, length and direction. The device writes the <bytes> `A`, `B`, `C`, `D` into that <DMA buffer>. After completion and any required <DMA buffer synchronization>, the <CPU> can read those four <bytes>. There are four payload <bytes>, but no four-item <CPU> copy loop on the device-to-<computer memory> path. This is a schematic example, not an instruction to operate real hardware.
\Image[/dma-data-and-control-paths.png]
{title=<DMA> separates the device-to-<computer memory> data path from <CPU> setup and completion control}
The useful separation is that the <CPU> can perform other work while a larger transfer proceeds. The reasoning is a division of responsibilities: setup specifies the destination and extent once; the transfer engine advances through the payload; completion reports the result. The data still crosses an interconnect such as a <computer bus>, which must share access among competing initiators. Setup, mapping, synchronization and completion cost work, so <DMA> does not promise a speedup for every transfer size. https://docs.kernel.org/core-api/dma-api.html[James E. J. Bottomley, Linux DMA API, parts Ic–Id: mapping costs, addressing constraints and transfer directions]{ref}
Correctness also requires keeping the <DMA buffer> alive and coordinating its ownership until the device is finished. A <DMA address> need not equal a <CPU> <virtual address> or <physical address>. An <IOMMU>, when present and configured, translates device addresses and can restrict access to authorized <computer memory>; it is not the <CPU>'s <memory management unit>. <Operating-system process> isolation through <virtual memory> alone does not establish those device-access restrictions. https://docs.kernel.org/core-api/dma-api-howto.html[Linux kernel documentation, Dynamic DMA mapping Guide: CPU and DMA addresses]{ref}https://docs.kernel.org/driver-api/vfio.html[Linux kernel documentation, VFIO: IOMMU protection and device isolation]{ref}
Back to article page
