阿里云郑晓分享：轻松理解GPU虚拟化技术（第三章）-探索SRIOV的奥秘
谈起GPU SRIOV那么这个世界上就只有两款产品：S7150和MI25。都出自AMD，当然AMD的产品规划应该是早已安排到几年以后了，未来将看到更多的GPU SRIOV产品的升级换代。S7150针对的是图形渲染的客户群体，而MI25则针对机器学习，AI的用户群体。本文以围绕S7150为主。因为S7150的SRIOV实例在各大公有云市场上都有售卖，而MI25目前看来尚未普及（受限于AMD ROCm生态环境的完备性）。
-
两个术语：SRIOV的PF，VF
（专业人士请自动忽略这部分介绍
）
PF：宿主机上的主设备，宿主机上的GPU驱动安装在PF上。PF的驱动是管理者。它就是一个完备的设备驱动，与一般的GPU驱动的区别在于它管理了所有VF设备的生命和调度周期。比如下图的07:00.0便是PF设备
VF：也是一个PCI设备，如下图中的07:02.0和07:02.1。QEMU在启动过程中通过VFIO模块把VF 作为PCI直通设备交由虚拟机，而虚拟机上的操作系统会安装相应的驱动到这个直通的VF PCI 设备上（07:02.0）。VF设备占用了部分GPU资源。比如下图中一个PF上面划分出了两个VF，那么很有可能跑在VF上面的虚拟机GPU图形渲染性能宏观上是PF的1/2。
上图是一个带有4个S7150的服务器，并且每个S7150 SRIOV虚拟出2个vGPU。
-
GPU SRIOV的本质
SRIOV的本质是把一个PCI卡资源（PF）拆分成多个小份（VF），这些VF依然是符合PCI规范的endpoint设备。由于VF都带有自己的Bus/Slot/Function号，IOMMU/VTD在收到这些VF的DMA请求的过程中可以顺利查找IOMMU2ndTranslation Table从而实现GPA到HPA的地址转换。这一点与GVT-g和Nvidia的GRID vGPU有本质上的区别。GVT-g与Nvidia GRID vGPU并不依赖IOMMU。其分片虚拟化的方案是在宿主机端实现地址转换和安全检查。应该说安全性上SRIOV方法要优于GVT-g和GRID vGPU，因为SRIOV多了一层IOMMU的地址访问保护。SRIOV代价就是性能上大概有5%左右的损失（当然mdev分片虚拟化的MMIO trap的代价更大）。由于SRIOV的优越性和其安全性，不排除后续其他GPU厂商也会推出GPU SRIOV的方案。
-
关于SRIOV 更多的思考
SRIOV也有其不利的地方比如在Scalable的方面没有优势。尤其是GPU SRIOV，我们看到的最多可以开启到16个VM。设想如果有客户想要几百个VM，并都想要带有GPU图形处理能力（但是每个VM对图形渲染的要求都很低），那么SRIOV的方案就不适用了。如果有一种新的方案可以让一个GPU的资源在更小的维度上细分那就完美了。事实上业界已经有这方面的考虑并付诸实践了。