Open DemiMarie opened 5 months ago
This could be very interesting! Our use case is slightly different in that we need to support things like CUDA, would that be tenable in this situation? If not, we may have to still retain support for NVIDIA vGPUs in our commercial product.
This could be very interesting! Our use case is slightly different in that we need to support things like CUDA, would that be tenable in this situation? If not, we may have to still retain support for NVIDIA vGPUs in our commercial product.
I’m not very familiar with how Nvidia vGPU works, but my understanding is that it uses mediated devices. Does the vGPU Manager use a kernel module (other than nvidia.ko
)?
It uses the standard kernel modules, so nvidia.ko and friends :)
It uses the standard kernel modules, so nvidia.ko and friends :)
Does it support the open source versions?
This allows for GPU acceleration without the firmware/hardware nightmare that is PCI passthrough. It is in production in ChromeOS for Qualcomm GPUs, under development for Intel, AMD, and GPUs, and neither requires nor uses GPU hardware virtualization support. It works by forwarding the GPU kernel driver API, which is already a security boundary. Most kernel driver vulnerabilities are mitigated, as ioctl submission is serialized and arguments are at least somewat validated.
Qubes OS will be using native contexts for GPU virtualization (https://github.com/QubesOS/qubes-issues/issues/8552) and I am interested in collaborating on the implementation. I presented on this at Xen Project Summit 2024.