目录
两种 vGPU 解锁方案的架构对比
经验分享：对于不在 NVIDIA GRID 驱动原生 vGPU 白名单内的显卡（如消费级 GTX/RTX 系列，或在新版本驱动中被移除 profile 的旧专业卡），社区有两条成熟的解锁路线——
vgpu_unlock-rs（运行时 LD_PRELOAD 拦截）和vGPU-Unlock-patcher（安装前离线修改驱动包）。本文把两条路的核心思路、拦截点和取舍对比清楚，不绑定具体型号。
背景
NVIDIA GRID vGPU 驱动启动时对显卡做两道硬检查：
- 准入检查：
nvidia-vgpud看设备 ID 在不在驱动内置的匹配臂里（Pascal/Volta/Ampere 等架构），不在就直接拒绝。 - 配置查表：准入后，驱动拿设备 ID 去
vgpuConfig.xml里查"这个 ID 下有哪些 vGPU profile"，查不到就不暴露mdev类型。
不在白名单或 profile 被移除的显卡两道都过不了。两条解锁路线就是在不同的环节把这两道拦下来。
路线一：vgpu_unlock-rs — 运行时拦截
拦截点：daemon 启动之后、系统调用之前。
正常装 GRID 驱动 → 编译 libvgpu_unlock_rs.so → systemd drop-in 注入 LD_PRELOAD → daemon 启动时 so 劫持设备 ID 查询 → 替换成一张有 profile 的卡 → 驱动以为这是支持的型号
核心是一个 Rust 写的 .so，通过 LD_PRELOAD 注入到 nvidia-vgpud 和 nvidia-vgpu-mgr 两个守护进程。daemon 查设备 ID 时，so 拦截系统调用，把真实 ID 替换成伪装目标的 ID，驱动拿着伪装后的 ID 去查表 → 命中 profile → 暴露 mdev 类型。
核心步骤：
- 正常安装 GRID 驱动（不做任何修改）
- 克隆
vgpu_unlock-rs，修改src/lib.rs——把目标显卡的设备 ID 加进对应架构的匹配臂，并指定伪装目标（一张驱动配置文件里有 profile 的卡） cargo build --release编译.so- 给两个 daemon 加 systemd drop-in，注入
LD_PRELOAD指向.so - 重启 daemon
特点：
- 不碰驱动安装包：正常安装
.run，不需要提前修改。 - 不改内核模块：只拦截用户态 daemon 的系统调用。
- 改伪装目标很快：
src/lib.rs改一行设备 ID，cargo build --release增量编译几秒完成。 - 伪装目标受限于
vgpuConfig.xml：每个驱动版本砍了哪些卡的 profile 不一样，得挑一个"还在配置文件里且架构匹配"的目标。
路线二：vGPU-Unlock-patcher — 离线修改驱动包
拦截点：驱动安装之前，直接改安装包里的文件。
拿到 GRID .run → patch.sh 三板斧 → 产出 *-patched/ 驱动 → 安装 → 就是"破解版"
三板斧分别解决不同层面的问题：
斧一：vcfgclone — 改 vgpuConfig.xml
把一张有 profile 的卡的条目克隆到目标显卡的设备 ID 下。这样配置文件里目标卡名下就有了完整的 vGPU profile 定义，不需要伪装设备 ID。这是它比 vgpu_unlock-rs 更彻底的地方——直接在配置层解决问题。
斧二：cvgpu.c — 编译 libvgpucompat.so
C 写的内核 ioctl 拦截库，作用和 vgpu_unlock-rs 的 .so 完全等价——都是 LD_PRELOAD 劫持设备 ID 查询。gcc 编译成 .so 后放 /usr/lib/x86_64-linux-gnu/，通过 ld.so.preload 或 systemd drop-in 注入。
斧三：blob-*.diff — patch 内核模块二进制
直接改 nvidia.ko 等内核模块的十六进制，从最底层绕过 GPU 检查。这是版本敏感的：diff 是针对特定驱动版本做的，换版本几乎一定不匹配。项目脚本用 patch -f（强制、忽略失败），且没有 set -e，版本不对时静默跳过——你以为打了补丁，实际上没打，不会报错。
三条斧各有独立性：不装内核补丁（斧三），仅靠斧一 + 斧二通常也能工作。斧一改配置文件、斧二做运行时拦截，两者互补。
对比总表
| 维度 | vgpu_unlock-rs | vGPU-Unlock-patcher |
|---|---|---|
| 拦截时机 | 运行时（daemon 启动） | 安装前（离线改包） |
| 落地方式 | 正常装驱动 + LD_PRELOAD | 改完驱动包再装 |
| 改配置文件 | 不碰 vgpuConfig.xml | 斧一 vcfgclone 直接加条目 |
| 内核模块 | 不碰 | 斧三 blob patch（版本敏感） |
| 伪装机制 | 运行时替换设备 ID | 斧一直接在配置里加目标卡条目 |
| 换驱动版本 | 改一行伪装目标，重编 .so（几秒） | 重新跑 patch.sh 全流程 |
| 运行时依赖 | 依赖 LD_PRELOAD + daemon drop-in | 装完即可，无额外运行时依赖 |
| 语言/工具链 | Rust + cargo | C + gcc + bash |
| 维护成本 | 低 | 中高（每版要重打三板斧，内核补丁需更新 diff） |
选择建议
两条路线的核心差异在拦截点和维护成本：
- vgpu_unlock-rs 在运行时劫持，不碰驱动包本身。换驱动版本只需改一行伪装目标、重编
.so。适合频繁更新驱动、追求最小改动的场景。 - vGPU-Unlock-patcher 在安装前改包，装完就是"破解版"，无运行时注入依赖。但内核模块 patch（斧三）版本敏感，换版本要重走全流程。适合"装一次用很久"的场景。
实际使用中，两条路线可以互补：先用 patcher 的 vcfgclone 直接给目标卡在配置文件里加条目（斧一），如果还不够，再上 vgpu_unlock-rs 或 libvgpucompat.so（斧二）做运行时兜底。内核模块 patch（斧三）作为最后手段，版本匹配时才考虑。
参考资料
- vgpu_unlock-rs — Rust 版 LD_PRELOAD 拦截库
- vgpu_unlock — 上游项目
- vGPU-Unlock-patcher — 离线改包路线
ai协作，人工编辑