虚拟化与分区技术：GPU虚拟化架构
各位同学，今天我们聊聊GPU虚拟化。说实话，这个主题我做了快十年，踩过的坑能写一本小册子。虚拟化听起来高大上，但说白了就是——怎么让多个用户或虚拟机，安全地共享一块GPU。
我见过不少团队，一上来就追求全虚拟化，结果性能惨不忍睹。也见过直接上直通模式的，安全隔离又出问题。嗯，这里头门道不少，我们一个一个说。
GPU虚拟化的三种架构
先理清概念。GPU虚拟化架构，主流有三种：全虚拟化、半虚拟化、直通。我习惯把它们比作租房模式——
- 全虚拟化：好比房东（Hypervisor）全权代理。租客（虚拟机）以为自己住的是独栋，其实所有请求都要经过房东转手。好处是兼容性好，坏处是性能损耗大。
- 半虚拟化：租客知道自己不是独栋，主动配合房东。性能比全虚拟化好，但需要修改Guest OS的驱动。
- 直通：直接把房子钥匙给租客。性能最好，但隔离性最差，而且一台GPU只能给一个租客用。
我在项目中遇到过一家客户，做云游戏的。他们一开始用全虚拟化，结果帧率掉了一半。后来改成半虚拟化，配合SR-IOV，才把性能拉回来。你想想看，游戏玩家对延迟多敏感，差一帧都能骂街。
全虚拟化（Full Virtualization）
全虚拟化下，Hypervisor拦截所有GPU命令。Guest OS以为自己独占GPU，实际上所有指令都要经过VMM（虚拟机监视器）翻译。
关键点：全虚拟化不需要修改Guest OS，兼容性最好。但每次命令翻译都有开销，尤其是频繁的小命令，性能损耗明显。
我曾经帮一个AI训练平台做优化。他们用全虚拟化跑TensorFlow，结果训练速度只有裸机的60%。排查下来，问题出在频繁的GPU内存分配上——每次分配都要经过VMM，开销太大了。
半虚拟化（Para-Virtualization）
半虚拟化要求Guest OS安装特定的前端驱动。前端驱动知道自己在虚拟化环境中，会主动把命令打包成高效格式，直接发给后端驱动。
说白了，就是租客主动配合房东，省去了翻译环节。性能比全虚拟化好不少，但需要修改驱动——这对闭源GPU驱动来说，是个麻烦事。
我的建议：如果你能控制Guest OS的驱动栈，半虚拟化是性价比最高的选择。我在做嵌入式GPU虚拟化时，就用的半虚拟化方案，性能损失控制在10%以内。
直通（Passthrough）
直通模式最简单粗暴——直接把物理GPU分配给一个虚拟机。性能几乎无损，但隔离性为零。而且，一块GPU只能给一个虚拟机用，资源利用率低。
我记得有个客户做视频渲染农场，每台服务器配了4块GPU，每块直通给一个虚拟机。结果呢？有的虚拟机闲得发慌，有的排队排到天荒地老。资源调度完全靠人工，效率极低。
注意：直通模式虽然性能好，但一旦出问题，整个虚拟机可能崩溃。我曾经因为直通GPU的DMA操作越界，导致宿主机直接蓝屏。嗯，从那以后我再也不敢在生产环境随便用直通了。
SR-IOV在GPU中的应用
SR-IOV（Single Root I/O Virtualization）本来是网卡虚拟化的技术，后来被移植到GPU上。它的核心思想是：让物理设备自己管理虚拟化，而不是靠软件模拟。
SR-IOV把物理GPU分成多个PF（Physical Function）和VF（Virtual Function）。PF是管理通道，VF是数据通道。每个VF看起来就像一个独立的GPU，有自己的队列、内存空间和寄存器。
| 特性 | 全虚拟化 | 半虚拟化 | SR-IOV |
|---|---|---|---|
| 性能损耗 | 高（20-40%） | 中（10-20%） | 低（<5%） |
| 隔离性 | 好 | 好 | 硬件级隔离 |
| 兼容性 | 最好 | 需修改驱动 | 需硬件支持 |
| 资源利用率 | 高 | 高 | 中 |
我在设计某款GPU IP时，就集成了SR-IOV支持。每个VF分配独立的命令队列和页表，硬件自动做地址翻译。Guest OS直接操作VF，不需要经过Hypervisor。性能几乎和裸机一样。
但SR-IOV也有坑。VF的数量是固定的，比如一块GPU最多支持64个VF。如果你需要更多虚拟机，就得用软件再分一层。我曾经遇到一个场景，客户要跑200个轻量级容器，每个容器都要访问GPU。SR-IOV的VF不够用，最后只能混合使用SR-IOV和半虚拟化。
避坑指南：SR-IOV的VF数量由硬件决定，设计时一定要预留余量。我曾经因为VF数量不够，被迫重新流片——那叫一个肉疼。
硬件分区（Hardware Partitioning）实现
硬件分区，说白了就是把GPU的物理资源切分成多个独立区域。每个区域有自己的计算单元、显存和带宽。区域之间完全隔离，一个区域出问题，不影响其他区域。
我参与过一款车规级GPU的设计，要求ASIL-B级别的安全隔离。软件虚拟化根本达不到要求，只能上硬件分区。
硬件分区的实现方式主要有三种：
- SM分区：把Streaming Multiprocessor（流式多处理器）分成多个组，每个组独立调度。我在项目中用的是4个SM一组，每组有自己的调度器。
- 显存分区：把显存分成多个bank，每个分区独占一部分。地址翻译在硬件层面完成，一个分区不能访问另一个分区的数据。
- 带宽分区：通过QoS机制，保证每个分区的最小带宽。我习惯用令牌桶算法，每个分区每秒有固定数量的令牌，用完就得等。
你想想看，如果GPU同时跑自动驾驶的感知算法和仪表盘渲染，感知算法出问题导致仪表盘黑屏——那可就出大事了。硬件分区就是防止这种连锁反应。
我的经验：硬件分区设计时，要特别注意分区粒度的选择。粒度太细，硬件开销大；粒度太粗，隔离效果差。我一般建议以4-8个SM为一个分区单位，显存以256MB为最小分配单元。
最后说一句，硬件分区不是万能的。它增加了芯片面积和功耗，而且分区数量固定后，灵活性就差了。我见过一些设计，为了追求极致隔离，把GPU分成了32个微分区，结果每个分区性能惨不忍睹。嗯，这里头有个平衡点，需要根据实际场景来定。
好了，关于GPU虚拟化与分区技术，今天就聊到这里。下一章我们讲内存安全与地址隔离，那又是另一个精彩的话题。