Jean-Philippe Brucker of ARM sent a 37-part patch, adding SVA support to Linux kernel, excerpts of announcement below:

Shared Virtual Addressing (SVA) is the ability to share process address spaces with devices. It is called “SVM” (Shared Virtual Memory) by OpenCL and some IOMMU architectures, but since that abbreviation is already used for AMD virtualisation in Linux (Secure Virtual Machine), we prefer the less ambiguous “SVA”. Sharing process address spaces with devices allows to rely on core kernel memory management for DMA, removing some complexity from application and device drivers. After binding to a device, applications can instruct it to perform DMA on buffers obtained with malloc.

The device, buses and the IOMMU must support the following features:
* Multiple address spaces per device, for example using the PCI PASID (Process Address Space ID) extension. The IOMMU driver allocates a PASID and the device uses it in DMA transactions.
* I/O Page Faults (IOPF), for example PCI PRI (Page Request Interface) or Arm SMMU stall. The core mm handles translation faults from the IOMMU.
* MMU and IOMMU implement compatible page table formats.

This series requires to support all three features. I tried to facilitate using only a subset of them but enabling it requires more work. Upcoming patches will enable private PASID management, which allows device driver to use an API similar to classical DMA, map()/unmap() on PASIDs. In the future device drivers should also be able to use SVA without IOPF by pinning all pages, or without PASID by sharing the single device address space with a process. Although we don’t have any performance measurement at the moment, SVA will likely be slower than classical DMA since it relies on page faults, whereas classical DMA pins all pages in memory. SVA mostly aims at simplifying DMA management, but also improves security by isolating address spaces in devices. Intel and AMD IOMMU drivers already offer slightly differing public functions that bind process address spaces to devices. Because they don’t go through an architecture-agnostic API, only integrated devices could use them so far. […]

Full patch:
https://lists.linuxfoundation.org/pipermail/iommu/2018-February/025992.html
More info on IOMMUs:
http://pages.cs.wisc.edu/~basu/isca_iommu_tutorial/index.htm
https://github.com/chipsec/chipsec/blob/master/chipsec/hal/iommu.py
https://www.spinics.net/lists/arm-kernel/msg609771.html
https://www.spinics.net/lists/kernel/msg2651481.html
https://www.spinics.net/lists/kvm/msg148819.html
https://developer.arm.com/products/architecture/a-profile/docs/100940/latest/separation-of-kernel-and-application-virtual-address-spaces
https://software.intel.com/en-us/articles/opencl-20-shared-virtual-memory-overview
https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/sharedVirtualMemory.html
https://lwn.net/Articles/726606/

Click to access 48882_IOMMU.pdf

https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
https://software.intel.com/en-us/blogs/2009/03/02/intels-virtualization-for-directed-io-aka-iommu-part-1