KVM 内实现 NVIDIA GPU 近原生访问
Virtio-nvgpu: Near-native Nvidia GPU access inside a KVM guest
virtio-nvgpu 项目让 KVM 虚拟机内的 NVIDIA GPU 性能接近裸机水平，渲染开销仅相差 2%。它通过在驱动 ABI 层面转发 ioctls，绕过传统 API 翻译，使 Guest 能直接运行未修改的 NVIDIA 用户态驱动。这意味着 Vulkan 渲染、NVENC 编码等任务可在虚拟机内高效完成，且 CPU 开销与宿主机几乎一致。实测显示，单张 RTX 3060 可同时支持四个 Guest 流畅运行，为无头流媒体场景提供了理想的解决方案。
在每帧耗时超过 2 毫秒的情况下——也就是游戏渲染的每一帧——Guest 的性能与裸机相差不到 2%。
HN 评论区
65- refibrillator
给 KVM 客户机配备 GPU 大致有三种方法。
1) VFIO 直通：宿主机将整个 GPU 作为 PCI 设备绑定给客户机，这意味着只有一台虚拟机能使用该 GPU，因此你也会牺牲掉宿主机的显示输出（除非你回退到 CPU 的核显等）。隔离性最强，因为不涉及宿主机内核模块驱动。
2) virtio-gpu：客户机看到的是半虚拟化 GPU，并加载 virgl/venus mesa 驱动，该驱动会序列化图形 API 调用并在宿主机驱动上重放。这允许多台虚拟机共享 GPU，但性能开销可能很大，而且客户机实际上无法利用 NVENC 等底层原语，除非付出 CPU 读回的代价。
3) virtio-nvgpu（本仓库）：客户机加载标准的 NVIDIA 用户态驱动（闭源），一个假的 /dev/nvidia* 内核模块会将 ioctl 字节 + 句柄复制到队列中，供宿主机内核态驱动执行。这也允许多台虚拟机共享 GPU，且由于开销低，速度接近原生。不幸的是，权衡之处在于此项目的隔离性最弱，例如默认情况下每个客户机的 ioctl 都会转发给宿主机，VMM 持有读写文件描述符，没有 seccomp/caps/白名单。关于 GPU 相关的安全措施，这里基本上为零，其暴露面与在没有虚拟机的情况下运行多个使用 GPU 的进程是一样的。唯一的限制是这些客户机无法驱动物理显示器，所以攻击面有所限制，但感觉这是 incidental（偶然的）而非 intentional（故意的）。
总之，这是一个棘手的问题……
- mjg59
嗯，关于在没有 IOMMU 限制的直通情况下，显卡对宿主机的访问级别，似乎缺乏讨论。
- mcmatterson
太棒的项目了！但是天哪，那个 README 简直就是 LLM 词藻堆砌的教科书式案例。这些工具在很多方面能力惊人，但写出来的东西却显得格格不入，真是让人大开眼界。
- jadera
我最近用 cgroups2 和 lxc 做了类似的事情。
这是一个 proxmox 宿主机，本地 lxc 通过 drm 直通用于显示器和 udev 外设，然后将 nvidia cuda api 通过 cgroup 分配给其他流式 lxc。这样我可以在本地节点玩游戏，朋友也可以远程在我的电脑上玩，而不会有人完全占用 GPU。
这里是技术文章（AI 生成）：
https://git.sahkoinsinoorikilta.fi/joona/hyper-converged-gam...
- orphereus
为什么不使用普通的 GPU 直通呢？我没看出这东西如何能在多个虚拟机之间共享 GPU，那么相比于使用 vfio-pci 驱动的普通 GPU 直通，使用这个软件的好处是什么？