There are roughly 3 ways to give a KVM guest a GPU.<p>1) VFIO passthrough: host binds entire GPU to guest as PCI device, which only allows one VM to use the GPU, thus you sacrifice your host display too (unless you fallback to integrated graphics on cpu etc). Strongest isolation because host kernel module driver not involved.<p>2) virtio-gpu: guest sees paravirtual GPU and loads virgl/venus mesa driver which serializes graphics API calls and replays them on the host driver. This allows multiple VMs to use the GPU, but performance overhead can be significant, and guests can’t practically leverage lower level primitives eg NVENC without paying price of CPU readback.<p>3) virtio-nvgpu (this repo): guest loads standard NVIDIA user mode driver (closed source), a fake /dev/nvidia* kernel module copies ioctl bytes + handle onto queue for host kernel mode driver to execute. This also allows multiple VMs to use a GPU, but is near native speed due to low overhead. Unfortunately the tradeoff is this project has the weakest isolation, eg every guest ioctl is forwarded to the host by default, the VMM holds read/write FDs, no seccomp/caps/allowlist. With respect to There is basically no GPU related security measures here, the exposure is the same as running multiple processes using the GPU with no VM. Only caveat is these guests can’t drive a physical display, so there is some restriction of surface area but it feels incidental rather than intentional in this case.<p>Anyways this is a tough problem OP, I don’t want to discourage you.<p>Without hardware/driver support for isolation (MIG) on consumer grade NVIDIA GPUs, it won’t be possible to solve this properly for a long time.<p>Also a factor is that NVIDIA has no open Mesa driver to support a native context approach (guest owns GPU command buffers, host maps them) like we have for AMD/Intel.
Hrm, something of a lack of discussion about what level of access the card has to the host in the absence of IOMMU-restricted passthrough.
I recently did a similar thing with cgroups2 and lxc<p>Its an proxmox host with local lxc drm passtrough for monitor + udev perhiperals, then cgroup the nvidia cuda api to other stream lxcs. this way i can play on my local node and friends can play on my pc remotely without anyone hogging the gpu fully.<p>Here is the writeup(AI gen):
<a href="https://git.sahkoinsinoorikilta.fi/joona/hyper-converged-gaming-server" rel="nofollow">https://git.sahkoinsinoorikilta.fi/joona/hyper-converged-gam...</a>
Amazing project! But man, that README is just a textbook example of LLM word salad. It's wild how these tools are so incredibly capable at many things, but their writing sticks out like a sore thumb
The percentage-overhead comparison is pretty choice nonsense. It has only percentages to try and "explain" that overheads don't matter if the system is slow anyhow.<p>A fair comparison would be this project vs virtio.
Virtio? what virtio? virtio native drm native context, is that what you mean? We actually use it in nesbox[1] for AMD/Intel cards.<p>Venus is the only one we could directly compare to, as it is the only one that supports Nvidia GPUs. vDRM works only on AMD/Intel GPUs and has a similar performance (~98% baremetal performance) to virtio-nvgpu.<p>[1] <a href="https://github.com/nestrilabs/nesbox" rel="nofollow">https://github.com/nestrilabs/nesbox</a>
When the lines in the ASCII charts don't even line up my immediate assumption is that the author didn't even bother to glance at it.
Claude is much worse for having a distinctive style you can spot from a mile away. I’ve found GPT-6 to not suffer from this or it’s insanely verbose markdown salad.
My bad, i am not a native English speaker... I did my best to try and brush it up. Terribly sorry if it did not match your flow.
LLMs are pretty good at translation, they're just pretty awful at generating natural-sounding English prose from scratch. In my opinion, probably the best solution is to simply write the README in your native tongue and use an LLM to translate it.
All good friend! I'm as guilty as anyone. It's a super cool project though.<p>Now that I have you on the hook, is there any benefit to this over virtio for a single KVM passthrough situation? I previously ran a proxmox based gaming PC setup (docs here: <a href="https://github.com/mtrudel/rabble/tree/4d9329f3dd0fb09123a8f40b7bff3329a8273b11" rel="nofollow">https://github.com/mtrudel/rabble/tree/4d9329f3dd0fb09123a8f...</a>), and was lucky enough that the GPU passthrough part of that build 'just worked'. I'd started down a path of trying to share the GPU between VMs based on a naive 'one VM owns it at a time' setup, but never really got it off the ground.
The benefit is that you do not have a limit to how many VMs you can run at the same time. However, virtio-nvgpu has no Windows support as of yet, please check back in a while :)<p>You should check out Nestri [1], another project we are working on, that helps you do exactly that. It helps run multiple gaming sessions for you and your friends on the same GPU, without anyone meddling in the other person's session. Everyone gets to stream their game to whatever desktop or device they want. It is still a work-in-progress though.<p>[1] <a href="https://github.com/nestrilabs/nestri" rel="nofollow">https://github.com/nestrilabs/nestri</a>
it's not just literary authorship, it's pretty easy to spot LLM driven programming paradigms too, especially if you look at the test suites of a given package.
Smells like KVM/VM escape to host.
Why not use normal GPU passthrough? I don't see how you can use this to share a GPU between multiple VMs, so what is the benefit of using this software over normal GPU passthrough with vfio-pci drivers?
With normal passthrough, your host loses access to the gpu, no? So you need to have two gpus, one for the host and one for the guest. Correct me, if I am wrong, but this should make the host fully operational on a single gpu and still let vm guests have headless access to the host gpu.
README mentions it supports up to 4 guests at a time sharing the GPU.
How is this different than gVisor's nvproxy? <a href="https://gvisor.dev/docs/user_guide/gpu/#compatibility" rel="nofollow">https://gvisor.dev/docs/user_guide/gpu/#compatibility</a><p>Edit: nvproxy is mentioned as the "direct inspiration" in the readme without mention of how this is different or why it doesn't use nvproxy as a backend.
We borrowed a lot of the architectural design from nvproxy, then built it to support graphical workloads. Plus it is reusable in such a way you can hot plug it into any microVM, cloud-hypervisor, maybe even Firecracker
Nesbox also just submitted today with similar intents. Except it also allows sharing the GPU across multiple guests.
<a href="https://news.ycombinator.com/item?id=49824884">https://news.ycombinator.com/item?id=49824884</a><p>Nesbox is just an underlying part of a broader (but early) kit to allow a system to <i>stream</i> multiple remote desktops at once.
<a href="https://github.com/nestrilabs/nestri" rel="nofollow">https://github.com/nestrilabs/nestri</a>
Can this be used with proxmox?
What are the isolation implications?
Does it work under OpenStack?
Can this be used with a Windows guest?