设备环境：Hyper-V虚拟机，系统fnOS 1.1.23
BUG现象：在使用 Hyper-V 虚拟机部署飞牛 OS，并通过 DDA 技术直通 Nvidia Tesla P4 显卡时，遇到了一个底层驱动完美运行，但影视应用无法调用 GPU 转码的 Bug。
出现频率：必现
联系方式：13124783926，微信同号
我在使用 Hyper-V 虚拟机部署飞牛 OS，并通过 DDA 技术直通 Nvidia Tesla P4 显卡时，遇到了一个底层驱动完美运行，飞牛系统可以正确识别显卡，但影视应用无法调用 GPU 进行转码的 Bug。
查阅论坛后已经多篇文章提到了Hyper-V直通显卡后无法调用GPU转码的问题
关于hyper-v的显卡DDA直通问题
windows server 2025 hyper v直通dg1
经过排查，我判断问题是由于 Hyper-V DDA 生成的非标准 PCIe Domain/Bus ID 导致 mediasrv 解析硬件路径失败引起的。以下是详细的排查报告，希望能帮助团队复现并修复此问题。
一、运行环境信息
- 宿主机： Windows Server 2022 (Hyper-V)
- 虚拟机： 飞牛 OS (fnOS) 最新版
- 直通方式： Hyper-V DDA (离散设备分配)
- 显卡型号： Nvidia Tesla P4 (纯计算卡，无显存输出接口)
- 驱动版本： 560.28.03（通过飞牛 Web UI 应用中心官方安装）
二、问题现象
三、深度排查与日志分析
为了定位阻断点，我进行了以下排查：
1. 确认系统节点生成正常：
-
执行 ls -l /dev/nvidia*：nvidia0, nvidiactl, nvidia-uvm 均正常生成且具备读写权限。
-
执行 ls -l /dev/dri：存在 renderD128 和 card0。
-
本来没找到/dev/nvidia-modeset，还以为是这个问题，手动创建后导致系统崩溃，猜测是Tesla P4为Headless GPU，不存在modeset。
-
执行 cat /sys/class/drm/renderD128/device/vendor：输出结果为 0x10de，确认该 DRM 渲染节点属于直通的 Nvidia 显卡，而非 Hyper-V 虚拟显卡。
2. 核心报错日志定位： 查看 /usr/trim/logs/mediasrv.log，发现在点击选择 GPU 时，后台持续报错：
[error] couldn't get card path, gpu device 'GP104GL [Tesla P4]', vendor 'NVIDIA Corporation'
[warning] no gpu working, force using cpu transcoding
3. 潜在可能的原因：Hyper-V 的非标准 Bus ID 对比 nvidia-smi 的输出信息，发现在 Hyper-V DDA 直通环境下，系统分配的 Bus-Id 为： Bus-Id: 0000A2BD:00:00.0
四、核心原因总结
在常规物理机或 PVE/ESXi 环境下，PCIe Bus ID 通常是规整的（如 0000:01:00.0）。但在 Hyper-V DDA 中，为了隔离硬件，微软分配了一个冗长且带有字母的虚拟 PCIe Domain 域（即本例中的 0000A2BD）。
飞牛内置的 mediasrv 服务在试图将通过 NVML 获取到的显卡信息与 /sys/class/drm/ 下的 card path 进行匹配绑定时，大概率是因为其匹配规则（如正则解析或路径截取代码）未兼容这种长格式/非标准的 PCI Domain ID，导致解析失败，在目录树中“迷路”，最终抛出 couldn't get card path 的错误并回退到 CPU 转码。
按照这个逻辑去猜测，应该所有通过Hyper-V DDA直通显卡的人都无法正常在影视中调用GPU进行转码，但是不知道为啥在论坛中有不少相册AI是可以调用GPU的，但影视也是表示均无法使用。
五、改进建议
建议研发团队核查 mediasrv 中用于探测和匹配 DRM 渲染节点的代码逻辑，兼容并放宽对 PCIe Domain ID 格式的解析规则，使其能够正确识别 Hyper-V 等特定虚拟化环境下生成的带有十六进制字母的长格式 Bus ID。
期待飞牛 OS 越来越好！如果需要更多配合测试，随时可以联系我。
