在 GPU 虚拟化中，"让 guest 如何能看到并使用 host 端真实硬件"是一条主线。本文按虚拟化方式把相关技术细化为四类——直通（Pass-through）、硬件分区（SR-IOV）、中介直通（Mediated）、API 转发（Paravirtual），逐层剖析实现原理、内核栈、优缺点与 AMD 平台落地方式。
目标：讲清每种技术里 “guest 看到的硬件” 究竟是什么、host 侧靠什么机制把真实 GPU 暴露/切分给 guest。
0. 总览：一张分类图
按"guest 看到的东西离真实硬件有多近"排序，从最近（几乎是裸金属）到最远（纯软件抽象）：
| 维度 | Passthrough | SR-IOV | Mediated (mdev) | API 转发 |
|---|---|---|---|---|
| Guest 看到的硬件 | 完整真实 GPU | 标准 PCIe VF | 中介虚拟设备 | 虚拟 GPU |
| 共享能力 | 独占（1:1） | 硬件多分区（1:N） | 软件时分/空分（1:N） | 高度共享（1:N） |
| 隔离机制 | IOMMU | 硬件 + IOMMU | 硬件上下文 + 软件调度 | 软件 |
| 性能 | 最高（≈裸金属） | 高 | 中 | 较低 |
| Guest 驱动 | 原生 | 原生/精简 VF 驱动 | 原生（配 host 中介） | virtio-gpu 前端 |
| AMD 代表 | VFIO 直通 | MxGPU / GIM | —— | virtio-gpu (venus) |
1. 直通类：PCI Passthrough（VFIO / IOMMU）
1.1 原理
把整块物理 GPU从 host 上解绑，通过 IOMMU 直接映射进一个 guest 的地址空间。Guest 里看到的是真实的 PCIe 设备（真实的 Vendor/Device ID、BAR、配置空间），用原生驱动直接操作。
关键硬件依赖：
- IOMMU（IntelVT-d/ AMDAMD-Vi / IOMMU v2）：负责 DMA 地址翻译与隔离，保证 guest 发起的 DMA 只能访问分配给它的内存。
- 中断重映射（Interrupt Remapping）：把设备中断安全地投递给正确的 guest。
1.2 内核栈（Linux）
关键组件：
vfio-pci：host 端接管 GPU 的占位驱动（替换掉amdgpu/nvidia）。vfio_iommu_type1：管理 IOMMU 域和 DMA 映射。- QEMU
-device vfio-pci,host=xx:yy.z：把设备暴露给 guest。
典型绑定流程：
# 1. 解绑原生驱动，绑定 vfio-pciecho"0000:03:00.0">/sys/bus/pci/devices/0000:03:00.0/driver/unbindecho"1002 744c">/sys/bus/pci/drivers/vfio-pci/new_id# 2. QEMU 直通qemu-system-x86_64-devicevfio-pci,host=03:00.0...1.3 优缺点
| 优点 | 缺点 |
|---|---|
| 性能最高，≈裸金属 | 一张卡只能给一个 VM（独占） |
| Guest 用原生驱动，功能完整 | 无法超分/共享，密度低 |
| 实现相对简单，成熟稳定 | GPU 复位、直通迁移较难 |
适用场景：单租户高性能计算、AI 训练、需要完整 GPU 功能的场景。
2. 硬件分区类：SR-IOV（Single Root I/O Virtualization）
2.1 原理
SR-IOV 是PCIe 规范级别的硬件能力。一个物理设备暴露：
- PF（Physical Function）：完整功能，由 host 驱动管理，负责资源分区与配置。
- 多个 VF（Virtual Function）：每个 VF 是一个"轻量级 PCIe 设备"，拥有独立的配置空间、BAR、DMA 上下文，但共享 PF 的部分底层资源。
每个 guest直通一个 VF，看到的是接近真实的标准 PCIe 设备。GPU 内部的硬件调度器在多个 VF 之间做时分/空分复用。
2.2 AMD 实现：MxGPU / GIM
AMD 的 SR-IOV GPU 虚拟化方案叫MxGPU，host 端驱动是GIM（GPU-IOV Module）：
- GIM运行在 host（hypervisor），管理 PF，配置 VF 数量、显存分区、调度时间片（World Switch）。
- World Switch：GPU 硬件在 VF 之间切换整个执行上下文（寄存器、页表、队列状态），实现时分复用。
- Guest 里跑标准amdgpu VF 驱动，通过邮箱（mailbox）机制与 PF/GIM 通信（如请求 GPU 复位、报告状态）。
关键点：显存和部分引擎是空分（每个 VF 分到固定显存段），计算引擎时间片是时分（World Switch 轮转）。
2.3 其他厂商实现
| 厂商 | 方案 | 说明 |
|---|---|---|
| AMD | MxGPU / GIM | SR-IOV 硬件分区，World Switch 时分 |
| NVIDIA | vGPU（Ampere/Hopper） | 新架构用 SR-IOV VF；MIG 可再做空分硬件隔离 |
| Intel | Flex 系列 SR-IOV | 数据中心 GPU 的 SR-IOV 分区 |
补充：NVIDIA MIG（Multi-Instance GPU）是更强的空分硬件隔离——把 GPU 的 SM、L2、显存控制器物理切成独立实例，可与 SR-IOV 叠加。它比纯时分的 World Switch 隔离性更强，但属于 NVIDIA 专有能力。
2.4 优缺点
| 优点 | 缺点 |
|---|---|
| 硬件级隔离，安全性好 | 需要硬件+固件支持（不是所有卡都有） |
| 一卡多 VM，密度高 | VF 数量、显存分区通常固定，弹性有限 |
| Guest 近似原生性能 | 授权/固件成本（部分厂商收费） |
适用场景：云 GPU、VDI、多租户推理，需要在共享与隔离间平衡。
3. 中介直通类：Mediated Device（mdev / GVT-g）
3.1 原理
对于没有 SR-IOV 硬件的 GPU，Linux 内核提供mdev（Mediated Device）框架用软件方式做分区。Host 驱动把一个物理 GPU 切成多个"中介设备"，guest 看到一个部分模拟 + 部分直通的混合设备：
- 性能关键路径（如帧缓冲、部分寄存器）走直通，接近原生。
- 控制/敏感路径（如上下文切换、特权寄存器）走 host 驱动软件中介（trap-and-emulate）。
3.2 代表实现：Intel GVT-g（KVMGT）
Intel 集显的GVT-g是 mdev 最经典的实现：
- Host 驱动
i915内嵌 GVT 模块，通过 mdev 暴露多个 vGPU。 - 全 GPU 上下文切换：软件调度器在多个 guest 的渲染上下文间切换（软件版 World Switch）。
- 影子页表（Shadow Page Table）：host 维护 guest GPU 页表的影子副本，保证 DMA 隔离。
创建 mdev 实例：
# 列出支持的 mdev 类型ls/sys/class/mdev_bus/0000:00:02.0/mdev_supported_types/# 创建一个 vGPU 实例echo"$(uuidgen)">.../mdev_supported_types/i915-GVTg_V5_4/create3.3 优缺点
| 优点 | 缺点 |
|---|---|
| 不需要 SR-IOV 硬件，成本低 | 软件中介有性能开销 |
| 共享灵活，可软件调度 | 隔离性弱于硬件分区 |
| 内核标准框架（mdev/VFIO） | 维护复杂，厂商支持在收缩（GVT-g 已逐步退场） |
适用场景：轻量图形虚拟化、旧硬件复用、桌面 VDI。
4. API 转发类：Paravirtual GPU（virtio-gpu / API Remoting）
4.1 原理
Guest 里看不到真实硬件，看到的是一个虚拟 GPU 设备。Guest 把图形/计算 API 调用（OpenGL/Vulkan）序列化成命令流，转发给 host；host 用真实 GPU执行后把结果返回。本质是"设备接口虚拟化 + 命令转发"。
4.2 代表实现
| 方案 | 转发的 API | 说明 |
|---|---|---|
| VirGL | OpenGL | virtio-gpu + virglrenderer，最早的开源 3D 转发 |
| Venus | Vulkan | virtio-gpu 的 Vulkan 后端，命令更接近原生，开销低 |
| API Remoting | 各类 | 桌面虚拟化（VMware SVGA、Parallels）的通用思路 |
- Guest 内核驱动：
virtio-gpu（标准 virtio 设备）。 - Guest 用户态：Mesa 的
virgl/venusGallium/Vulkan 驱动。 - Host：
virglrenderer（含 venus）把命令流翻译成 host GPU 的真实 API 调用。
4.3 优缺点
| 优点 | 缺点 |
|---|---|
| 高度共享，不占用独立硬件资源 | 性能最低，转发有开销 |
| 无需特殊 GPU 硬件能力 | 功能受 renderer 支持范围限制 |
| Guest 完全解耦具体 GPU 型号，易迁移 | 计算（compute）支持不如图形成熟 |
适用场景：桌面虚拟化的 3D 加速、容器/沙箱图形、跨型号可迁移场景。
5. 横向对比与选型建议
5.1 综合对比表
| 技术 | Guest 看到 | 共享 | 隔离 | 性能 | 硬件要求 | AMD 落地 |
|---|---|---|---|---|---|---|
| Passthrough | 完整真实 GPU | 1:1 独占 | IOMMU | ★★★★★ | IOMMU | VFIO 直通 |
| SR-IOV | 标准 VF | 1:N 硬件分区 | 硬件+IOMMU | ★★★★☆ | SR-IOV 固件 | MxGPU/GIM |
| Mediated | 中介设备 | 1:N 软件调度 | 硬件上下文+软件 | ★★★☆☆ | 无特殊要求 | —— |
| API 转发 | 虚拟 GPU | 1:N 高度共享 | 软件 | ★★☆☆☆ | 无特殊要求 | virtio-gpu/venus |
5.2 选型决策
核心区分点：
- 想让 guest 看到"真实/接近真实硬件"→Passthrough或SR-IOV（硬件辅助，性能最好）。
- 想在共享的同时仍暴露"设备"→mdev/GVT-g（中介直通）。
- 不要求看到真硬件→virtio-gpu/API 转发（半虚拟化）。
5.3 AMD 平台聚焦
结合本仓库的 amdgpu / ROCm SVM 工作，最相关的两条路线：
- VFIO Passthrough：把整卡直通给一个跑 ROCm 的 guest，SVM、KFD、原子操作等功能与裸金属一致——因为 guest 用的是完整的原生
amdgpu+ KFD 栈。 - SR-IOV（MxGPU/GIM）：多租户共享时，guest 跑 amdgpu VF 驱动，通过 mailbox 与 PF 通信。需要注意 VF 模式下部分特权操作（GPU 复位、某些寄存器）要经 PF 中介，SVM/一致性行为可能受 World Switch 与显存分区影响。
6. 参考锚点
- IOMMU / VFIO：Linux
Documentation/driver-api/vfio.rst - SR-IOV：PCIe SR-IOV 规范；AMD GIM（
GPUOpen/GIM） - mdev：Linux
Documentation/driver-api/vfio-mediated-device.rst；Intel GVT-g - virtio-gpu / venus：Mesa
virgl/venus，virglrenderer
