Proxmox GPU passthrough failing? Find the stage that breaks.

Passthrough is a custody handoff, not a checkbox

At every moment, exactly one thing owns your GPU. At power-on it is the firmware, which may draw the boot screen on it. Then a host driver such as nouveau or amdgpu may grab it. For passthrough, vfio-pci has to take every function in the card’s IOMMU group. Then the guest drives it. When the guest shuts down, the card has to reset cleanly so the next owner gets a working device.

The failures this guide covers are each one of those handoffs going wrong: the firmware framebuffer keeps a BAR, a host driver keeps the audio function, another group member stays with the host, or the card never comes back from reset. So the most useful question is not “what is wrong with my VM config?” but “who owns the card right now?”. On the host, lspci -nnk answers that with one line per function.

Why does GPU passthrough fail on Proxmox?

Treat passthrough as a chain of five stages. Each needs evidence from the host before you change anything in the guest; a guest driver reinstall cannot fix a host that never released the card.

1. Confirm the IOMMU and interrupt remapping

sudo dmesg | grep -e DMAR -e IOMMU -e AMD-Vi
sudo dmesg | grep 'remapping'
ls /sys/kernel/iommu_groups/ | wc -l
cat /proc/cmdline

Enable VT-d or the AMD IOMMU in firmware. AMD enables the IOMMU by default. Proxmox documents Intel as on by default from kernel 6.8, and intel_iommu=on as needed before that. Proxmox VE admin guide source: PCI(e) passthrough. Where a kernel parameter goes depends on whether the host boots with GRUB or systemd-boot; follow the Proxmox VE wiki: host bootloader and kernel command line for your host.

Proxmox also requires interrupt remapping. Look for lines such as AMD-Vi: Interrupt remapping enabled or DMAR-IR: Enabled IRQ remapping in x2apic mode. Without it, the documented workaround is options vfio_iommu_type1 allow_unsafe_interrupts=1, which Proxmox warns can make the system unstable. Treat it as a deliberate, recorded exception. Proxmox VE wiki: PCI passthrough, GPU notes and ACS override.

2. Check the GPU’s IOMMU group

Run pvesh get /nodes/{nodename}/hardware/pci --pci-class-blacklist "" with your node name, or the shell loop in IOMMU groups explained. Proxmox documents sharing a group with the GPU’s own functions, its root port or a bridge as acceptable. Proxmox VE admin guide source: PCI(e) passthrough. Any other endpoint in the group (a USB, SATA or network controller) blocks a clean assignment.

Paste the listing into the IOMMU group checker to see which functions travel together. If the group is shared, work through the slot, firmware and ACS options in the IOMMU groups guide before going further: nothing in stages 3 to 5 can make a shared group viable.

3. Make vfio-pci own every GPU function

Proxmox tries to release a device from its host driver when the VM starts. If that fails, or a host driver grabs the card at boot, bind it statically. Find the IDs and the current owner first:

# Example address: use your GPU’s bus and device number.
lspci -nnk -s 01:00

Then load the VFIO modules and claim the GPU’s IDs. The IDs and drivers below match the synthetic example further down; use the ones lspci -nnk reports on your host.

# /etc/modules-load.d/vfio.conf
vfio
vfio_iommu_type1
vfio_pci

# /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:2684,10de:22ba
softdep nouveau pre: vfio-pci
softdep snd_hda_intel pre: vfio-pci

update-initramfs -u -k all
# Reboot the host, then:
lsmod | grep vfio
lspci -nnk -s 01:00

Every GPU function should show Kernel driver in use: vfio-pci. Proxmox VE admin guide source: PCI(e) passthrough. Older guides also load vfio_virqfd; current Proxmox documentation lists only the three modules above, because newer kernels build that code into vfio.

Blacklisting the host driver (nouveau, nvidia*, amdgpu, radeon or i915) is the blunter alternative. Blacklisting i915 also removes the driver from an Intel integrated GPU the host may be using. Proxmox VE wiki: PCI passthrough, GPU notes and ACS override.

4. Match the VM settings to the GPU

For GPU passthrough, Proxmox recommends the q35 machine type, OVMF (UEFI) firmware and PCIe mode. OVMF needs a GPU ROM with UEFI support. Proxmox VE admin guide source: PCI(e) passthrough.

qm config 101 | grep -e machine -e bios -e hostpci
# Pass all functions of 01:00 (no ".0"), in PCIe mode, as the primary GPU:
qm set 101 -hostpci0 01:00,pcie=on,x-vga=on

• All functions. 01:00 passes every function, like the GUI’s All Functions checkbox. 01:00.0 passes only the graphics function and leaves the audio function on the host.
• pcie=on works only with the q35 machine type.
• x-vga=on marks the card as the guest’s primary GPU.
• romfile points to a ROM file under /usr/share/kvm/, for cards whose ROM the VM cannot use directly.
• No picture in the console? A passed-through GPU’s output does not appear in noVNC or SPICE. Use a monitor on the card, or remote desktop inside the guest.
• Large-memory cards can need a bigger 64-bit MMIO window under OVMF. The Proxmox wiki lists options such as the host CPU type or phys-bits. Proxmox VE wiki: PCI passthrough, GPU notes and ACS override.

5. Make sure the host has let go of the card

If the GPU drew the host’s boot console, a firmware framebuffer can still hold part of its memory. The Proxmox wiki lists BAR 3: can't reserve in the host log as a sign of this and suggests video=efifb:off. Proxmox VE wiki: PCI passthrough, GPU notes and ACS override. Find out what holds the region before adding parameters:

sudo journalctl -k -b --no-pager | grep -i -e vfio -e "can't reserve"
# Find the address range from the error and see which driver claimed it:
sudo cat /proc/iomem

The wiki also notes that disabling CSM (legacy boot) in firmware avoids legacy VGA initialisation on single-GPU hosts. Keep another way into the host, such as SSH or a second GPU, before you take away its only display.

6. Test the reset lifecycle, not only the first start

Start the VM, use the GPU, shut the guest down cleanly and start it again. Record the host’s view of the card each time.

lspci -nnk -s 01:00
cat /sys/bus/pci/devices/0000:01:00.0/reset_method
sudo journalctl -k -b --no-pager | tail -n 50

reset_method lists the resets the kernel can use for the function. Linux ABI: PCI sysfs attributes, link speed and reset_method. Its presence does not promise that a reset recovers the card from every state. The Proxmox wiki notes that some AMD cards, Navi among them, suffer from the “AMD reset bug”. The vendor-reset project supplies device-specific resets for a listed set of AMD GPUs; check that list for your exact card before adding an out-of-tree module. vendor-reset: device-specific reset module and supported hardware.

If the card becomes unreadable after a VM stops, with rev ff or an unknown header type, follow unknown PCI header type 127 in passthrough.

Annotated example: “group 1 is not viable”

# Synthetic example for illustration: not captured from a real host.
$ qm config 101 | grep hostpci
hostpci0: 0000:01:00.0,pcie=1,x-vga=1

$ qm start 101
kvm: -device vfio-pci,host=0000:01:00.0,…: vfio 0000:01:00.0: group 1 is not viable
Please ensure all devices within the iommu_group are bound to their vfio bus driver.

$ lspci -nnk -s 01:00
01:00.0 VGA compatible controller [0300]: Synthetic demo GPU [10de:2684] (rev a1)
	Kernel driver in use: vfio-pci
	Kernel modules: nouveau
01:00.1 Audio device [0403]: Synthetic demo GPU HDMI audio [10de:22ba] (rev a1)
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

Two fixes fit this evidence: assign all functions (qm set 101 -hostpci0 01:00,pcie=on,x-vga=on), or add the audio ID to vfio-pci ids= as in stage 3. Then start the VM again and confirm vfio-pci on both functions. If group 1 also held a USB or SATA controller, binding the audio function would not be enough; go back to stage 2.

Questions

Why does GPU passthrough fail on Proxmox?

Check five host-side stages in order: the IOMMU and interrupt remapping are enabled; the GPU has a clean IOMMU group; vfio-pci owns every GPU function; the VM uses settings that suit the card (q35, OVMF, all functions); and the card resets between VM runs. Fix the first stage that fails.

Why is the screen black when the VM starts?

A passed-through GPU’s output never appears in the Proxmox noVNC or SPICE console. Check a monitor connected to the GPU itself. If that is also blank, check the host log for vfio and BAR reservation errors and whether OVMF can use the card’s ROM.

Do I still need vfio_virqfd?

Not on current kernels. Current Proxmox documentation lists vfio, vfio_iommu_type1 and vfio_pci. Older guides add vfio_virqfd, which newer kernels no longer ship as a separate module.

Is iommu=pt required for GPU passthrough?

No. Proxmox describes it as optional and says it may improve performance where supported. It does not enable the IOMMU and does not change IOMMU groups.

What is the AMD reset bug?

Some AMD GPUs do not return to a usable state after a VM releases them, so the next VM start can fail until the host is restarted. The vendor-reset project covers a listed set of AMD cards; check the list for your exact model.

Should I use the ACS override to split the GPU’s group?

Only as a last option, knowing that it removes the kernel’s isolation check without adding isolation. Try a CPU-attached slot and firmware options first. The IOMMU groups guide explains the risk.