3.4.3 GPU 虚拟化技术
1. GPU 虚拟化
当前可以商用的 GPU 虚拟化模式可以分为GPU 直通模式、GPU SR-IOV 模式和 GPU 半虚拟化模式。后两种模式属于 GPU 分片虚拟化模式。
GPU 直通模式
GPU 直通模式是对物理机性能损耗最小的方案，被各云服务提供商广泛采用。GPU 直通模式如图 3-27 所示。它没有对 GPU 功能性做任何限制，兼容性也最好。在GPU 直通模式下，物理机的 GPU 驱动可以直接安装到虚拟机内使用。该模式的缺点也很明显，首先直通模式不支持热迁移，在宿主服务器上无法对设备进行操作，其次它缺少设备的监控数据。
GPU Driver GPU Hypervisor GPU1 GPU2 GPU2⋯⋯ 虚拟机宿主服务器
图 3-27 GPU 直通模式
GPU SR-IOV 模式
当前只有 AMD 的两款 GPU 产品支持 SR-IOV 模式：S7150 和 MI25。S7150 针对图形渲染的场景，MI25 则针对机器学习领域。阿里云 GPU 云服务器的 GA1 系列采用的就是 S7150，GA1 规格族中的小规格实例采用的是 SR-IVO 方案。将一个物理 GPU 做 SR-IOV 分片虚拟化处理。图 3-28 所示的GPU SR-IVO 模式是一个物理 GPU 102
通过 SR-IOV 的驱动虚拟出多个虚拟机 GPU。SR-IOV 标准是一种基于硬件的虚拟化解决方案，可提高性能和可伸缩性。
vGPU 驱动 vGPU Hypervisor GPU VF GPU VF2 GPU VF⋯⋯ 虚拟机服务器硬件 GPU PF GPU SR-IOV 驱动 Host Linux
图 3-28 GPU SR-IOV 模式
图 3-29 是 GPU SR-IOV 技术架构图，在虚拟化软件栈中加入了 GIM 模块来驱动 GPU 硬件。GIM 模块调用 PCI 子系统接口初始化 SR-IOV 虚拟功能（Virtual Function，VF），并 对硬件资源进行管理分配。VFIO 模块可通过标准的 PCI 设备接口直接使用虚拟功能。虚拟机实例中图形驱动程序将发送请求给 GIM 模块，由其将 虚拟功能使能并调度到硬件资源上运行。GIM 的运行对虚拟化环境而言完全透明，与直通技术没有差别。由于 GPU SR-IOV 使用标准的直通接口把虚拟 GPU 资源分配给虚拟机，所以虚拟机控制系统对其操作的接口与直通技术没有差别。
SR-IOV 技术有如下两种功能。
1）物理功能（Physical Function，PF）
宿主机上的物理主设备，宿主机上的 GPU 驱动安装在 PF 上。PF 的驱动是管理者。它是一个完备的设备驱动，与一般 GPU 驱动的区别在于它管理了所有 VF 设备的生命和调度周期，比如图 3-30 所示的 07：00.0 就是 S7150 的 PF 设备。
2）虚拟功能（Virtual Function，VF）
也是一个 PCI 设备，如图 3-30 中的 07∶02.0 和 07∶02.1。图 3-30 中的一个 PF （S7150）划分出了 4 个 VF，理论上运行在 1 个 VF 上面的虚拟机 GPU 的图形渲染性能是 PF 的 1/4。
在 GPU SR-IOV 方案中，把一个物理 GPU 设备（PF）拆分成多个小份虚拟机 GPU（VF），这些 VF 依然是符合 PCI 规范的 PCIe 设备。GPU SR-IOV 方案在虚拟比 1 ∶ 1 的情况下性能上大概有 5% 的损失。
QEMU VFIO Interface VM0 Guest Driver VM1 GIM KVM VFIO IOMMU IRQ 子系统VM2 VM3 VM4 Guest Driver Guest Driver Guest Driver Guest Driver QEMU QEMU QEMU QEMU PCI 子系统Linux Kernel DMAR IRQ remapping AMD GPU PCI config Mem BAR MMIO Regs VF0 VF1 VF2 VF3 PCI GPUIOV PF Video Mem System Mem
VF 分时复用 GPU 硬件资源，GIM 模块负责时间片调度，支持 Round-Robin 和 QoS 两种调度策略。VF 的调度是 GPU SR-IOV 中的重点，涉及如何服务虚拟机， 以及如何确保 GPU 资源的公平分片等。
GPU SR-IOV 也是一个分时复用的策略。GPU 分时复用与 CPU 在进程间的分时复用是一样的概念。一个简单的调度就是把一个 GPU 的时间按照特定时间段分片， 每 个 VF 拿到特定的时间片。在这些时间片段中，VFn 独自享有 GPU 硬件的全部资源。
目前所有的 GPU 虚拟化方案都采用了分时复用的策略。但不同的 GPU 虚拟化 方案在时间片的不同切片中会采用不同的方案。有些方案会在一个 GPU Context 的当前 batch buffer/cmd buffer 执行结束之后启动调度，并把 GPU 交由下一个时间片的所有者。有些方案则会严格要求在特定时间片结束的时候切换，强行打断当前 GPU 的工作，并交给下一个时间片的所有者。这种方案确保 GPU 资源被平均分摊到不同 VF。AMD 的 GPU SR-IOV 采用的是后一种方案。AMD 的 GPU 硬件设计保证了在任何 GPU Batch Buffer 的执行过程中可以被安全抢占，保障每个 GPU VF 具有同等的性能，理论上每个 GPU VF 的性能都是 GPU PF 的 1/N，N 是设定的虚拟比。
GPU SR-IOV 特性如下所述。
GPU 的显存是根据设定的虚拟比，由 GPU SR-IOV 驱动静态划分的，不可以 动态修改。
虚拟比最大为 16 ∶ 1（一个 GPU 最多虚拟出 16 个 vGPU），并且可以灵活配 置，支持的虚拟比有 16 ∶ 1、8 ∶ 1、4 ∶ 1、2 ∶ 1 和 1 ∶ 1。
每个 vGPU（VF）时间片都由 GPU SR-IOV 驱动（GIM）调度，每个 VF 时间片严格按照虚拟比来分配。不同 GPU VF 之间不会争抢资源。
GRID vGPU 简介
GRID vGPU 是 NVIDIA 的一项虚拟化技术，可以把一块 GPU 卡分片并分配给虚拟机使用，从虚拟机的角度来看，和 SR-IOV 一样，每个分片 vGPU 在物理上都是隔离的。GPU 分片虚拟化基于 VFIO Mediated Passthrough Framework 的 GPU 虚拟化方案。该方案由 NVIDIA 提出，并联合 Intel 一起提交到了 Linux Kernel 4.10 代码库，该方案的 Kernel 部分代码简称 mdev 模块，GRID vGPU 方案如图 3-31 所示。
阿里云的vgn5i 规格族实例基于 NVIDIA Tesla T4 显卡的 vGPU 方案，是国内首个公共云上的轻量级 GPU 规格族，提供比单个物理 GPU 更细粒度的服务，从而让用户可以更低成本、更高弹性地开展业务。
GRID vGPU 的优势
在 GPU 虚拟分片的场景下，一个物理 GPU 可以直通给多个虚拟机使用，如图 3-32 所示。和直通方案相比，具有如下优势。
vGPU Driver vGPU Hypervisor vGPU1 vGPU2 vGPU... 虚拟机服务器硬件 GPU Host vGPU Manager Host Linux mdev Framework ……
图 3-31 GRID vGPU 方案
可以更加灵活地选择 GPU 实例规格，降低成本。
将一块物理 GPU 同时共享给多个用户使用，避免不必要的资源浪费。
基于硬件虚拟化技术，可以完美地实现高性能 GPU 在硬件安全隔离下为多用户 所共享。
GPU 虚拟化损耗可忽略，严格保证每用户分配到的 GPU 能力互相无干扰。
支持热迁移，当宿主机发生异常时可以通过热迁移技术迁移 GPU 云服务器实例，保障用户业务不中断。
VM VM VM VM GPU GPU 宿主机
图 3-32 GPU 虚拟分片106
GPU 热升级和热迁移技术
1） GPU 热升级技术
虚拟化热升级技术已经在上一节介绍过，GPU 设备是通过VFIO 框架将设备移交到服务器内部的，在热升级的过程中，通过直通设备移交技术，实现GPU 服务器的QEMU 和KVM 的热升级。直通设备的热升级面对的最大问题是中断丢失。在热升级的过程中先中断CPU 的调度再中断设备，直接中断会造成数据丢失。热升级之后服务器的设备可能处于不可用的状态。在热升级过程恢复阶段，我们对有中断丢失的设备，根据中断类型不同重新给虚拟机注入一个虚拟中断。
2）vGPU 的热迁移技术
在GPU 虚拟化的场景下，Host 上有物理GPU 的驱动模块，可以操作和管理vGPU 的物理资源，这里可以类比KVM 对硬件资源的管理。此时QEMU 可以通过驱动模块获取vGPU 的所有数据来实现热迁移的功能。
vGPU 支持热迁移硬件和软件上的关键点。
寄存器支持保存和还原。
GPU 的显存（Framebuffer）硬件支持脏页跟踪Dirty Track 功能。
Framebuffer 的保存和还原要足够快。
vGPU 显存（Framebuffer）在热迁移流程中的处理方式和System Mem 是一样的， 首先需要打开GPU 的脏页跟踪功能，再在迭代拷贝阶段记录脏页。
在vGPU 运行时，寄存器保留一些中间状态和上下文，在目的主机恢复vGPU 调度之前，如果要保证vGPU 可以正常工作，能接着执行源端暂停的任务，那么需要在目的主机把GPU 的相关寄存器和上下文恢复。
GPU SR-IOV 和 GRID vGPU 两种GPU 分片模式都是支持热迁移的，阿里云和AMD 联合设计了基于SR-IOV 分片GPU 的热迁移架构，并在2018 年 KVM Forum 上做了分享和演示。图3-33 是vGPU 热迁移QEMU 对 GPU SR-IOV 处理的时序图。
QEMU 在源主机通过GIM API 修改vGPU 状态、拷贝寄存器和Framebuffer 的数据，在目的主机恢复初始化VF（vGPU）并恢复寄存器和Framebuffer 的数据。
如图3-34 所示，VM1 在Host1 上使用VF0，迁移到Host2 上使用VF1。当前SR-IOV GPU 的驱动GIM 把物理GPU 的Framebuffer 平均划分给VF，这种方案简化了迁移过程中GPU pagetable 的映射。
源主机目的主机
图 3-33 vGPU 热迁移QEMU 对GPU SR-IOV 处理的时序图
从Host1 的VF0 迁移到Host2 的VF1。blk1 的物理GPU 的Framebuffer 中的地址发生了变化，相对于VF0 和VF1 的基地址的偏移并没有发生变化。
目的主机GIM 对VF1 建立GPU pagetable 的表项， Guest OS 内的GPU Driver 对Framebuffer 的访问会被映射到VF1 的指定的地址空间内。
在VM 内部，迁移前后Guest OS 看到的设备并没有发生变化。Guest OS 记录的GPU 的设备上下文信息被保存/ 恢复之后，Guest OS 内的GPU Driver 看到硬件设备的状态没有发生改变，任务得以继续执行。
对于不支持脏页跟踪的GPU 设备，我们设计了一套软件支持GPU FrameBuffer Dirty 的方案，在迁移此类GPU 设备时，可以将 Service Downtime 优化到原来的二十分之一。对于中断丢失问题，热迁移采用的解决方案和热升级类似，重新给虚拟机注入中断。
图3-34 热迁移
