【https://www.jianshu.com/p/dd8ab6b68c6a
http://bbs.chinaunix.net/thread-2072818-1-1.html
IOMMU https://blog.csdn.net/sdulibh/article/details/86611777
https://blog.csdn.net/wentyoon/article/details/60144824
UIO https://blog.csdn.net/xy010902100449/article/details/46917623
https://www.cnblogs.com/SZLLQ2000/p/5257475.html
http://www.voidcn.com/article/p-umqpermh-no.html
http://www.voidcn.com/article/p-dpylthzt-gx.html
VFIO
这篇 https://hhb584520.github.io/kvm_blog/2017/04/14/passthrough.html
vfio使用参考kernel/Documentation/vfio.txt
UIO -->IOMMU --> VFIO
[转自 https://blog.csdn.net/zgy666/article/details/78649777]
---------------------
UIO
UIO
UIO 框架导出sysfs和/dev/uioX 2套用户态接口，用户对设备节点/dev/uioX进行设备控制，mmap()接口用于映射设备寄存器空间，write()接口用于控制中断关闭/打开，read()接口用于等待一个设备中断。
因为对于设备中断的应答必须在内核空间进行，所以在内核空间有一小部分代码用来应答中断和禁止中断，其余的工作全部留给用户空间处理。如果用户空间要等待一个设备中断，它只需要简单的阻塞在对 /dev/uioX的read()操作上。 当设备产生中断时，read()操作立即返回。UIO 也实现了poll()系统调用，你可以使用 select()来等待中断的发生。select()有一个超时参数可以用来实现有限时间内等待中断。
UIO的几个特点：
- 一个UIO设备最多支持5个mem和portio空间mmap映射。
- UIO设备的中断用户态通信机制基于wait_queue实现。
- 一个UIO设备只支持一个中断号注册，支持中断共享。
总的来说，UIO框架适用于简单设备的驱动，因为它不支持DMA，不能支持多个中断线，缺乏逻辑设备抽象能力。
IOMMU
我说的IOMMU是指位于北桥上的IOMMU,那种设备自带IOMMU的情况我还不了解。
在没有IOMMU的情况下，设备（指32bit或64bit设备，老的16bit的不提）的DMA操作可以访问整个物理地址空间，所以理论上设备可以向操作系统的代码段、数据段等内存区域做DMA，从而破坏整个系统。当然，通常来说不会有这样的设备。IOMMU的出现，可以实现地址空间上的隔离，使设备只能访问规定的内存区域。下面简要说一下intel的IOMMU怎么做到这点的：
目前PC架构最多有256PCI总线，于是IOMMU用一个称为root entry的数据结构描述PCI总线，总共256个root entry构成一张表。每条PCI总线最多允许256个设备，IOMMU用context entry描述一个PCI设备（或者是PCI桥），256个context entry构成一张表。所以就有了如图的关系。我们知道，PCI设备用 {BUS
EV:FUNC}（当然，还有个segment，不过似乎PC架构都只有一个segment，这个暂时忽略）描述一个设备。所以对于一个特定设备，用bus号做索引root entry表，用dev号索引context entry表可以找到描述该设备的的context entry。context entry中有一个指针指向一章I/O页表，当设备发起DMA操作时，IOMMU会根据该页表把设备的DMA地址转换成该设备可以访问内存区域的地址。
所以只要为设备建一张I/O页表，就可以使设备只能访问规定的内存区域了。当然，也可以把该页表当成跳板，让只能寻址32bit地址空间的设备访问到64bit地址空间中去。
Many platforms contain an extra piece of hardware called an I/O Memory Management Unit (IOMMU). An IOMMU is much like a regular MMU, except it provides virtualized address spaces to peripheral devices (i.e. on the PCI bus). The MMU knows about virtual to physical mappings per process on the system, so the IOMMU associates a particular device with one of these mappings and then allows the user to assign arbitrary bus addresses to virtual addresses in their process. All DMA operations between the PCI device and system memory are then translated through the IOMMU by converting the bus address to a virtual address and then the virtual address to the physical address. This allows the operating system to freely modify the virtual to physical address mapping without breaking ongoing DMA operations. Linux provides a device driver, vfio-pci, that allows a user to configure the IOMMU with their current process.
大概就是这么回事了，似乎写的有点乱，具体问题看spec。
VFIO
vfio使用参考kernel/Documentation/vfio.txt
上文提到，UIO不支持DMA，所以通过DMA传输大流量数据的IO设备，如网卡、显卡等设备，无法使用UIO框架，VFIO做为UIO的升级版，主要就是解决了这个问题。通过用户态配置IOMMU接口，可以将DMA地址空间映射限制在进程虚拟空间中。这对高性能驱动和虚拟化场景device passthrough尤其重要。
在VFIO框架中，有几个核心概念或对象：IOMMU、/dev/vfio、container、iommu_group。
- IOMMU是一个硬件单元，它可以把设备的IO地址映射成虚拟地址，为设备提供页表映射，设备通过IOMMU将数据直接DMA写到用户空间。之所以不共用MMU单元，是为了保证和进程的页表相互独立，防止设备访问进程的任意地址空间。所以VFIO的IOMMU功能保障了安全的非特权级别的用户态设备驱动机制。
- /dev/vfio是一个设备文件，作为一个IOMMU设备的用户态呈现。
- container是内核对象，表示一个IOMMU设备，是一个IOMMU设备的内核态呈现。所以在VFIO中，container是IOMMU操作的最小对象（container中有多个iommu_group）。
- 在虚拟化场景下，一个物理网卡可能要虚拟成几个虚拟网卡，或者说虚拟功能设备（VF），这几个VF共用一个IOMMU，所以VFIO模型增加一个iommu_group的概念，用来表示共享同一个IOMMU的一组device。
VFIO的几个特点：
- VFIO设备支持多中断号注册。
- 设备的中断用户态通信机制基于eventfd/irqfd实现。用户通过/dev/vfio设备select/poll/epoll，从而实现中断从内核态到用户态的异步事件通知。
- 支持对物理设备进行逻辑抽象。
- 仅支持pci intx中断共享，其他类型中断不支持共享。
- VFIO仅支持特定IOMMU设备，如x86与PowerPC平台的PCI设备和ARM平台的platform设备。
概述
VFIO是一套用户态驱动框架，它提供两种基本服务：
- 向用户态提供访问硬件设备的接口
- 向用户态提供配置IOMMU的接口
VFIO由平台无关的接口层与平台相关的实现层组成。接口层将服务抽象为IOCTL命令，规化操作流程，定义通用数据结构，与用户态交互。实现层完成承诺的服务。据此，可在用户态实现支持DMA操作的高性能驱动。在虚拟化场景中，亦可借此完全在用户态实现device passthrough。
VFIO实现层又分为设备实现层与IOMMU实现层。当前VFIO仅支持PCI设备。IOMMU实现层则有x86与PowerPC两种。VFIO设计灵活，可以很方便地加入对其它种类硬件及IOMMU的支持。
接口
与KVM一样，用户态通过IOCTL与VFIO交互。可作为操作对象的几种文件描述符有：
- Container文件描述符
- 打开/dev/vfio字符设备可得
- IOMMU group文件描述符
- 打开/dev/vfio/N文件可得 (详见后文)
- Device文件描述符
- 向IOMMU group文件描述符发起相关ioctl可得
逻辑上来说，IOMMU group是IOMMU操作的最小对象。某些IOMMU硬件支持将若干IOMMU group组成更大的单元。VFIO据此做出container的概念，可容纳多个IOMMU group。打开/dev/vfio文件即新建一个空的container。在VFIO中，container是IOMMU操作的最小对象。
要使用VFIO，需先将设备与原驱动拨离，并与VFIO绑定。
用VFIO访问硬件的步骤：
- 打开设备所在IOMMU group在/dev/vfio/目录下的文件
- 使用VFIO_GROUP_GET_DEVICE_FD得到表示设备的文件描述 (参数为设备名称，一个典型的PCI设备名形如0000:03.00.01)
- 对设备进行read/write/mmap等操作
用VFIO配置IOMMU的步骤：
- 打开/dev/vfio，得到container文件描述符
- 用VFIO_SET_IOMMU绑定一种IOMMU实现层
- 打开/dev/vfio/N，得到IOMMU group文件描述符
- 用VFIO_GROUP_SET_CONTAINER将IOMMU group加入container
- 用VFIO_IOMMU_MAP_DMA将此IOMMU group的DMA地址映射至进程虚拟地址空间
逻辑
VFIO设备实现层与Linux设备模型紧密相连，当前，VFIO中仅有针对PCI的设备实现层(实现在vfio-pci模块中)。设备实现层的作用与普通设备驱动的作用类似。普通设备驱动向上穿过若干抽象层，最终以Linux里广为人知的抽象设备(网络设备，块设备等等)展现于世。VFIO设备实现层在/dev/vfio/目录下为设备所在IOMMU group生成相关文件，继而将设备暴露出来。两者起点相同，最终呈现给用户态不同的接口。欲使设备置于VFIO管辖之下，需将其与旧驱动解除绑定，由VFIO设备实现层接管。用户态能感知到的，是一个设备的消失(如eth0)，及/dev/vfio/N文件的诞生(其中N为设备所在IOMMU group的序号)。由于IOMMU group内的设备相互影响，只有组内全部设备被VFIO管理时，方能经VFIO配置此IOMMU group。
把设备归于IOMMU group的策略由平台决定。在PowerNV平台，一个IOMMU group与一个PE对应。PowerPC平台不支持将多个IOMMU group作为更大的IOMMU操作单元，故而container只是IOMMU group的简单包装而已。对container进行的IOMMU操作最终会被路由至底层的IOMMU实现层，这实际上将用户态与内核里的IOMMU驱动接连了起来。
总结
VFIO是一套用户态驱动框架，可用于编写高效用户态驱动；在虚拟化情景下，亦可用来在用户态实现device passthrough。通过VFIO访问硬件并无新意，VFIO可贵之处在于第一次向用户态开放了IOMMU接口，能完全在用户态配置IOMMU，将DMA地址空间映射进而限制在进程虚拟地址空间之内。这对高性能用户态驱动以及在用户态实现device passthrough意义重大。