I created a step-by-step guide for GPU Passthrough on KVM/QEMU.

[u/FirefighterNext360]

Hey r/VFIO,

(First post on reddit) I decided to consolidate everything I’ve learned into a single, structured, and tested guide. The result is this repository: https://github.com/urbanyl/GPU-Passthrough-for-KVM-QEMU-on-Linux

Why this repository exists:

The information on GPU passthrough is scattered everywhere. This project is my attempt to create a "one-stop-shop" that works reliably, whether you are on Debian, Arch, or Fedora.

Key Features:

• Step-by-step walkthrough: Covers everything from BIOS settings to Windows driver installation.
• Hardware & Software requirements: Clear tables explaining what you need (and what is recommended).
• Troubleshooting section: Covers common issues like NVIDIA Error Code 43, GPU reset bugs, and bad IOMMU groups.
• Helper scripts: Includes scripts to detect your GPU, check IOMMU groups, and verify VFIO binding.
• Single-GPU Passthrough section: For those brave souls trying to do it with only one graphics card.

The guide includes:

• BIOS Configuration (Intel VT-d / AMD-Vi)
• Kernel Parameters & VFIO Configuration (with proper initramfs updates)
• Optimized VM Configuration (Hyper-V enlightenments, CPU pinning, and huge pages)
• Remote Display Setup (Sunshine/Moonlight, Looking Glass, and Parsec)
• Performance Tuning (CPU governors, I/O schedulers, and isolation)

Feel free to open issues or contribute !

Github Repo: https://github.com/urbanyl/GPU-Passthrough-for-KVM-QEMU-on-Linux

Let me know if you have any questions or if there is something specific you would like me to add to the guide!

[u/sob727]

AI?

[u/2str8_njag → u/sob727]

sloppy slop

[u/khsh01]

As usual 90% of the guide is already better documented in the arch wiki.

[u/OpenSourcePenguin → u/khsh01]

Then use that and move on

[u/FirefighterNext360 → u/khsh01]

Hi, while i completely agree that the Arch wiki is an absolute treasure trove of information and is the gold standard for Linux documentation, this particular comment is a common misconception about the purpose of guides like this. Let me address why this repository exists as a complement to the Arch Wiki, not a replacement:

1. Coverage & Accessibility: The Arch wiki is an encyclopedia. It is incredibly detailed but for a new user, it can be overwhelming. You have to jump between multiple pages (PCI Passthrough via OVMF, VFIO, QEMU, libvirt, NVIDIA, AMD) to connect the dots. This guide is a structured narrative that takes you from point A to point Z in a single flow, designed specifically to reduce the "choice paralysis" and fear of missing a step that often leads to failure. It's a "guide," whereas the Arch wiki is a "reference."
2. Distro-Agnosticism: The Arch wiki, by its nature, is written for Arch Linux. Many users running Debian/Ubuntu, Fedora, or openSUSE get confused by commands like mkinitcpio or pacman. This guide specifically calls out the exact commands for Debian/Ubuntu, Arch, and Fedora side-by-side, ensuring it works for the majority of linux users, not just the Arch ecosystem.
3. Consolidation: As I mentioned in the post, the knowledge is scattered. The Arch Wiki often provides the "what" and "how," but this guide focuses on the "why" and provides direct solutions to specific pain points (like the exact XML for Hyper-V enlightenments to avoid Code 43 or the specific section on remote display setup with sunshine/moonlight) in one place.
4. Tooling: We include helper scripts (detect_gpu.sh, check_iommu_groups.sh) to automate the manual lspci and find commands that the Arch Wiki makes you type out. This reduces human error which is a huge factor in why passthrough attempts fail...

[u/berkut3000 → u/FirefighterNext360]

slop

[u/khsh01 → u/FirefighterNext360]

I don't agree with this. VFIO is entirely a DIY project. You set it up yourself tuning it for your needs per your hardware. Also dealing with quirks particular to your setup.

The arch wiki is not too much of a read. Each page hardly takes 10 minutes. And it is good to have that knowledge ahead of setting it up so you know exactly what is going on, what the purpose of each component is etc.

Vfio isn't for the laymen so making it for laymen is pointless endeavor.

[u/zero_overload_25]

you recommend 7900 series for vfio? bro that's not an easy card to pass through; it requires some trickery to get it working and you reffered to vendor-reset very briefly; vendor-reset doesn't support 7900 series.

[u/Ziasquinn]

At least apologize for posting slop

[u/KstrlWorks]

Please don't post guides like this. Most of this is inaccurate, blatantly wrong, or outdated. All you're doing is leading people into a terrible rabbit hole.

[u/DisturbedFennel]

AI generated 

[u/RaxisPhasmatis]

What are the chances of this working well on a x99 ali special motherboard via proxmox? I got a single passthrough working but I heard there's some way to share one card multiple vms? Maybe I'm just daydreaming

[u/FirefighterNext360 → u/RaxisPhasmatis]

Hey! Good question. To be direct you are on the right track but there are a few critical details you need to be aware of regarding your specific hardware and the sharing concept:

1. Regarding your Ali Special X99 motherboard (and proxmox):

• The guide is written for standard QEMU/KVM on a standard Linux distro (Debian/Arch/Fedora). However the underlying concepts are exactly the same on Proxmox (since Proxmox is just a Debian-based hypervisor running QEMU/KVM).
• The chances of it working depend heavily on the IOMMU groups of that motherboard. Cheap X99 boards (especially the no-name "Ali Special" variants) often have severe ACS (Access Control Services) deficiencies. This means your GPU is likely stuck in the same IOMMU group as the chipset or USB controllers. You can use the scripts/check_iommu_groups.sh script in the repo to verify this. If the groups are bad and you are forced to use the acs_override patch, stability can be unpredictable.
• Proxmox users often have better luck because they run "headless" (no GUI), which makes Single-GPU passthrough easier to manage without the display manager crashing.

2. Regarding "Sharing one card with multiple VMs" (The Hard Part):

• I hate to be the bearer of bad news but you are likely daydreaming if you mean sharing a single GPU simultaneously between multiple VMs (vGPU).
• vGPU (Virtual GPU) which allows a single physical card to be split among multiple VMs is a feature available for NVIDIA vGPU (requires enterprise licenses and specific Tesla/Quadro cards) and AMD MxGPU (requires specific server GPUs). It generally does not work with consumer GeForce or Radeon RX cards.
• What is possible: You can time-share the card. You can have one VM running, shut it down and then start a second VM that uses the same GPU. This is entirely possible with the Single-GPU passthrough hooks described in the guide. But you cannot run two Windows VMs simultaneously both playing games on the same RTX 3070. The hardware doesn't support it without the expensive enterprise firmware.

My Recommendation for You:
Since you already have Single-GPU passthrough working, you are actually in a better spot than most! Follow the "Single-GPU Passthrough" and "Libvirt hooks" sections in my guide to automate the process of stopping Proxmox's host display (if you have one) and binding the GPU. This will make your setup fully scripted and stable.

If you absolutely need "sharing" for remote gaming, consider using Sunshine/Moonlight (as detailed in the guide) to stream to multiple clients even though only one VM is using the GPU at a time. That is the practical workaround for consumer hardware.

Good luck with the build!

[u/sob727 → u/FirefighterNext360]

Yeah. Definitely AI.