GPU虚拟化技术：
1 GPU 和软件架构
GPU可以用于图形渲染，GPU 作为加速图形绘制的芯片时，它主要面向的产品主要是会集中在 PC 和游戏两个市场。也能够用于高性能计算领域(GPGPU)和编解码场景(子模块)等。
下图将软件系统中的 GPU 子系统抽象了几层概念，在 GPU 上的经典软件架构（不含虚拟化），分别适用到 通用计算领域 和 图形渲染领域 两类场景。
图：GPU 的典型软件架构（不含虚拟化）
2 GPU 和虚拟化
虚拟化使用软件在计算机硬件上创建抽象层，能够将单个计算机的硬件元素（包括处理器、内存、存储器等）分成多个虚拟计算机，通常称为虚拟机 (VM)。 GPU 虚拟化是系统软硬件模拟 GPU 资源，以支持虚拟机方案。
3 GPU 虚拟化需求
体现在资源共享和资源隔离两方面
资源共享的需求：GPU 性能越来越强大，需要多租户（多容器和多虚机）共享资源。应用场景如多屏车机、本地桌面虚机、远程桌面（桌面虚拟化）、云 GPU 虚机。
资源隔离的需求：要保证多租户互不影响，应用场景如显存隔离、算力隔离、故障隔离。
4 GPU 虚拟化技术
虚拟化技术实现体现三个层次，即用户层、内核层和硬件层。然后在根据技术的应用场景分为隔离场景（容器和虚机）和硬件场景（虚拟桌面、渲染和 AI 计算）两个维度，不同的技术可能仅适用它对应的的场景。技术实现可分类为：
- 用户层：API 拦截和 API forwarding
- 内核层：GPU 驱动拦截
- 内核层：GPU 驱动半虚拟化：Para Virtualization
- 硬件层：硬件虚拟化：Virtualization
- 硬件层：SRIOV：Single Root I/O Virtualization
- 硬件层：Nvidia MIG：Multi-Instance GPU
5 GPU 用户层虚拟化
1）本地 API 拦截和 API forwarding
- 在用户态实现一个函数库，假设叫 libwrapper ，它要实现底层库的所有 API
- 让 APP 调用这个 libwrapper => 如何实现？底层动态库 + 用dlopen打开
- libwrapper 拦截用户的函数调用，对函数进行解析，然后使用参数去调用实际的底层库相同名称的函数
- 调用完成后，libwrapper 把结果返回给 APP
2）远程 API forwarding
- libwrapper 通过网络，去调用不同机器上的底层库
- libwrapper 变成两部分，client 用于转发，和 server 用于接收和调用
- 可以实现 GPU 池化（即多个 GPU 可以组成调用池，由多个 client 来调用），可以做到不具备 GPU 的机器能实现 GPU 的功能
3）半虚拟化 API forwarding
- APP 和 libwrapper 运行在虚机中
- libwrapper 通过半虚拟化方式（virtio）进行通讯，调用宿主机的底层库
- 虚机的内核要实现 virtio frontend => 优化点? 虚机和宿主机共享内存加速数据传递
- 宿主机的 hypervisor 实现 virtio backend
- 宿主机完成底层库的调用
6 GPU 内核层虚拟化
1）内核模块通过设备文件拦截
内核拦截模块模拟一个设备文件，内核拦截模块将用户进程的访问转发到（真实的）驱动软件，然后将对应内核函数的返回解析，再返回用户态。
- 通常底层库通过设备文件访问 GPU 驱动的功能，假设为
/dev/realgpu - 实现一个内核模块，输出模拟的设备文件给用户空间，假设为
/dev/realgpu - 把模拟的设备文件 bind mount 到容器里，伪装成真的设备文件
/dev/realgpu - APP 和底层库都在容器里运行，底层库访问伪装的设备文件
/dev/realgpu，此时所有访问被内核模块拦截
2）驱动半虚拟化
用户进程通过系统虚拟化层（hypervisor）提供的虚拟化接口，访问（真实的）虚拟化接口。
- APP 和底层库都在虚机里
- 虚机的 GPU 驱动实现半虚拟化接口，通过类似 hypercall 的方式，调用宿主机实际的 GPU 驱动
- hypercall 切换 guest 到 hypervisor， hypervisor 通过内核中的驱动代理来访问实际的 GPU 驱动
例如，车机中的 GPU 虚拟化。基于 type 1 的 hypervisor 虚拟化技术，支持多个 Guest。
7 GPU 硬件层虚拟化
虚拟化需要软件和硬件结合才能实现，其中需要硬件的支持的部分包括
- 支持 CPU 和内存的硬件虚拟化
- 支持 IOMMU
- DMA remapping和Interrupt remapping
- 硬件隔离和页表机制
8 GPU 全虚拟化
该方案实现了将整个 GPU 透传给虚拟，严格来说不算虚拟化领域，因为无法实现 GPU 资源共享。
- 虚机的 GPU 驱动，不需要做任何修改，基本上访问的是真实的硬件资源
- 整个 GPU 透传给虚机，性能损耗最小
- 因为无法实现 GPU 资源共享，一般认为不属于GPU 虚拟化
