虚拟化之mdev-vfio笔记

[root@master mdev]# vi Makefile

# SPDX-License-Identifier: GPL-2.0-only

mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o

obj-$(CONFIG_VFIO_MDEV) += mdev.o
obj-$(CONFIG_VFIO_MDEV_DEVICE) += vfio_mdev.o

如上，查看drivers/vfio/mdev/Makefile可以发现，mdev（Mediated Device）实际上是由两个而不是一个模块构成。

他俩是怎么分工的？

[root@custom-16-126 mdev]# lsmod |grep -i mdev
vfio_mdev 12841 0
mdev 20336 1 vfio_mdev
vfio 32656 3 vfio_mdev,vfio_iommu_type1,vfio_pci

从上面的模块可以看出，mdev模块是通用模块，虽然目前只有vfio_mdev来跟他适配，但设计来说，mdev可以看成bus总线，

比如pci总线，后面会有很多不同类型的pci总线设备接入，而vfio_mdev可以看做vfio驱动针对mdev总线的一种适配， vfio_mdev 与 vfio_pci的地位是一样的。

vfio_mdev.ko则是定义了mdev总线上的一种Driver，用来实现和VFIO的对接。

mdev出现的背景：

mdev的文档可以参考vfio-mediated-device.txt,就是内核源码自带的，他主要解决的问题是，不支持sr-iov的设备，如何做到切分，也就是说，虽然物理上

不支持vf的切分，他通过mdev，可以时分复用的方式来实现虚拟化，这样就实现了多个用户态驱动“同时“ 操作一块物理设备的能力。

我们为什么需要VFIO？一个原因是虚拟机经常时用直接设备访问(“device assignment”)来获得尽可能高的IO性能，

从设备和host的角度，这其实就是把VM变成了一个用户态驱动，VM也因此获得了这个IO设备的低延迟、高带宽和全虚拟化原生(bare-metal)设备驱动的直接应用。

从gpu虚拟化的角度来看，我们怎么看待sr-iov的虚拟化与mdev-vfio的趋势哪家会发展更好呢？

分片虚拟化不需要IOMMU硬件的支持。其只需要VFIO模块添加type1 IOMMU的驱动，来通知host将要进行的DMA传输的GFN，VA等信息，并在Host端的mdev设备驱动层完成GFN到PFN的翻译处理。

这个翻译是通过pin_page然后建好映射的方式来实现的，可以理解为软件层面上的IOMMU操作。

而AMD SRIOV与GPU passthrough方式下，IOMMU是必备组件。尤其IOMMU硬件完成GFN到PFN的地址转换，分片虚拟化对于不具备sr-iov虚拟化的硬件是一个很好的解决方案，但是从里面的原理

可以看出，这样方便了闭源的驱动加入到linux的家庭继续存在，其中以英伟达为最，因为它只要实现了mdev驱动要求的几个回调函数就行。既然是软件层面实现的iommu，那么意味着速度上肯定会

比硬件上慢，其实sr-iov的硬件，现在出现更多在网卡侧，比如智能网卡的产品落地，amd自从推出7150的显卡支持sr-iov之后，几年没有见到新的产品来支持sr-iov，而反观英伟达，借助mdev，将虚拟化做得风生水起。