abelardojarab/IOMMU support in Linux kernel.md

## IOMMU support in Linux kernel.md

      
    Raw
  

              IOMMU support in Linux kernel.md
            
          
    Basic stuff

ACPI enumerates and lists the different DMA engines in the platform, and
device scope relationships between PCI devices and which DMA engine  controls
them.
How is IOVA generated?

Well behaved drivers call pci_map_() calls before sending command to device
that needs to perform DMA. Once DMA is completed and mapping is no longer
required, device performs a pci_unmap_() calls to unmap the region.
The Intel IOMMU driver allocates a virtual address per domain. Each PCIE
device has its own domain (hence protection). Devices under p2p bridges
share the virtual address with all devices under the p2p bridge due to
transaction id aliasing for p2p bridges.
IOVA generation is pretty generic. We used the same technique as vmalloc()
but these are not global address spaces, but separate for each domain.
Different DMA engines may support different number of domains.
We also allocate guard pages with each mapping, so we can attempt to catch
any overflow that might happen.
Finding DMAR regions in Linux console

$ find /sys | grep dmar
/sys/devices/virtual/iommu/dmar0
...
/sys/class/iommu/dmar0
/sys/class/iommu/dmar1

  
## Verifying IOMMU support in Linux kernel.md

      
    Raw
  

              Verifying IOMMU support in Linux kernel.md
            
          
    Basic stuff

ACPI enumerates and lists the different DMA engines in the platform, and
device scope relationships between PCI devices and which DMA engine  controls
them.
How is IOVA generated?

Well behaved drivers call pci_map_() calls before sending command to device
that needs to perform DMA. Once DMA is completed and mapping is no longer
required, device performs a pci_unmap_() calls to unmap the region.
The Intel IOMMU driver allocates a virtual address per domain. Each PCIE
device has its own domain (hence protection). Devices under p2p bridges
share the virtual address with all devices under the p2p bridge due to
transaction id aliasing for p2p bridges.
IOVA generation is pretty generic. We used the same technique as vmalloc()
but these are not global address spaces, but separate for each domain.
Different DMA engines may support different number of domains.
We also allocate guard pages with each mapping, so we can attempt to catch
any overflow that might happen.
Finding DMAR regions in Linux console

$ find /sys | grep dmar
/sys/devices/virtual/iommu/dmar0
...
/sys/class/iommu/dmar0
/sys/class/iommu/dmar1