> ## Content Index
> Fetch the complete content index at: https://sudoreboot.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# Your GPU wants out of the host, and the VM is ready to adopt it
- URL: https://sudoreboot.me/gpu-passthrough-kvm/
- Published: 2026-09-14T12:00:00.000Z
- Updated: 2026-10-30T15:46:57.000Z
- Description: IOMMU groups, vfio-pci, and the ROM file nobody mentions until your screen stays black.
- Author: Jon
- Tags: Hardware, virtualization, kvm

Every home server has a graphics card sitting in it doing absolutely nothing while the VM next door would kill for it. Passing the whole GPU through to a virtual machine fixes that, and when it works, the guest barely knows it isn't running on bare metal. Gaming, video encoding, a bit of machine learning: all near-native. When it *doesn't* work, you get a black screen and no error messages. Here's how to land on the right side of that line.

## Step one: wake up the silicon

Head into the firmware setup and enable the CPU's virtualization extensions (Intel VT-x or AMD-V) *and* the IOMMU (Intel VT-d or AMD-Vi). The IOMMU is the bouncer that lets the hypervisor safely hand a PCI device to a guest. Then tell the kernel to actually use it:

```
# Intel
intel_iommu=on iommu=pt
# AMD (the IOMMU is usually on by default; iommu=pt still helps)
iommu=pt
```

`iommu=pt` (pass-through mode) spares the host's own devices from paying a translation tax.

## Read your IOMMU groups like tea leaves

Here's the rule that decides everything: a device can only be passed through together with everything else in its IOMMU group. So go look:

```
for g in /sys/kernel/iommu_groups/*; do
  echo "Group ${g##*/}:"
  for d in "$g"/devices/*; do echo "  $(lspci -nns "${d##*/}")"; done
done
```

The dream is a GPU and its HDMI audio function in a group all by themselves. If they're sharing with a USB controller or a chipset bridge, try another PCIe slot before anything else. Yes, the ACS override patch can split groups, but it works by *trusting* devices to keep to themselves. Treat it as the last resort it is.

## Keep the host's grubby hands off the card

Bind both functions of the GPU to `vfio-pci` at boot, using the vendor:device IDs from `lspci -nn`:

```
vfio-pci.ids=10de:2484,10de:228b
```

After a reboot, `lspci -nnk` should report `Kernel driver in use: vfio-pci` for both. If the host's graphics driver grabs the card first, the guest will boot just fine and stare at you with a black screen forever.

## Building the VM

- Use the **Q35** machine type and **OVMF** (UEFI) firmware.
- Add the video and audio functions as two functions of *one* device in the guest, not two separate cards.
- Set the CPU mode to `host-passthrough` and pin the virtual CPUs to physical cores (and their hyper-threads) that the host isn't busy with.
- If the card is the only GPU in the machine, it may need its video BIOS handed over as a ROM file, dumped from the card itself. The firmware already used the card during boot and the guest wants a fresh copy. This is the step most guides forget.

## The gotchas

- **Reset bugs.** Some cards don't reset cleanly when the VM stops, so the second boot hangs. Vendor-reset modules exist for the usual offenders, and a full host reboot always works.
- **Power.** The card draws from the host's power supply even while the VM is off. Check your PSU has headroom before you find out the exciting way.
- **Input.** Pass through a whole USB controller for keyboard, mouse and headset. It's far more reliable than passing individual USB devices one at a time.

Once it works, it's gloriously boring: the VM boots, the card shows up in the guest's device manager, and the host doesn't even notice it's gone. Boring is the goal.