Enable IOMMU and GPU Passthrough on Proxmox VE (September 2026)

If you have ever wanted to run a Windows gaming VM with near-native graphics, hand a workstation-class GPU to a Linux container, or isolate a GPU-intensive workload from your Proxmox host, you need GPU passthrough. On Proxmox VE 9, that process is more reliable than it has ever been, but only if IOMMU is enabled correctly. I have walked through this configuration on AMD Epyc servers, Intel consumer boards, and everything in between, and I will share the exact steps that work in 2026.

This guide covers enabling IOMMU and passing a GPU through to a VM on Proxmox VE 9 from the first BIOS screen to the final driver install. I will explain the differences between the EXT4 and ZFS bootloader paths, the kernel 6.8+ quirks that change which steps you need, and the AMD RDNA3/RDNA4 BIOS fix that catches almost everyone the first time. By the end you will have a passthrough-ready VM and a clear troubleshooting checklist when something goes wrong.

Prerequisites and Hardware Requirements

Before you touch any file on your Proxmox host, confirm your hardware actually supports IOMMU. CPU virtualization extensions alone are not enough. You need full IOMMU support in both the CPU and the chipset, plus a motherboard BIOS that exposes the relevant toggles.

For Intel systems, look for VT-d (Intel Virtualization Technology for Directed I/O) in the CPU specifications. Almost every Xeon and Core i5/i7/i9 since Sandy Bridge supports VT-d, but a few consumer K-series chips lock the feature behind a chipset limitation, so always check the official ARK page.

For AMD systems, AMD-Vi (also called AMD IOMMU) has been standard on Ryzen, Threadripper, and Epyc processors since the first generation. Threadripper and Epyc parts give you the cleanest IOMMU groups, but mainstream Ryzen works too if the BIOS exposes the right options.

Your motherboard also matters. Server boards (Supermicro, ASRock Rack, Dell PowerEdge) generally have the cleanest IOMMU groupings. Consumer boards, especially B550 and X570 chipsets, often share an IOMMU group between the top PCIe slot and the chipset downstream devices, which forces workarounds later in this guide.

For the GPU itself, pick one that supports UEFI GOP (Graphics Output Protocol). Every GPU made after roughly 2017 supports UEFI GOP out of the box. Very old Kepler cards and a handful of pre-2017 cards need a vBIOS dump and OVMF to start cleanly.

Confirm Proxmox VE 9 is freshly installed. You can run this guide on an upgraded host from 8.x, but for clarity the commands and examples below assume Proxmox VE 9 installed on EXT4 (BIOS bootloader). I will also call out the ZFS path differences where they apply.

BIOS Configuration Checklist

Most failed passthrough attempts trace back to a single missing BIOS option. Set everything below before you boot Proxmox for the first passthrough attempt, save and exit, then return here.

1. Enable IOMMU / VT-d / AMD-Vi. The exact label varies by vendor. On ASUS boards look for “AMD IOMMU”, on MSI it is “IOMMU”, on Intel boards it is “VT-d”.

2. Enable Above 4G Decoding. This is required for GPUs with large BAR (Base Address Register) regions, including NVIDIA 30-series and above and AMD RDNA2/3/4 cards with Resizable BAR.

3. Enable Resizable BAR / Smart Access Memory (optional but recommended). If your GPU and guest OS support it, enable this for an additional 5-15% performance in many games.

4. Disable IOMMU Pre-boot DMA Protection if you have an AMD RDNA3/RDNA4 GPU. This single toggle fixes passthrough for RX 7000 and RX 9000 series cards on Proxmox 9. You will find it under “IOMMU” or “PCI Subsystem Settings”.

5. Disable CSM (Compatibility Support Module). Modern GPUs assume UEFI-only environments. Leaving CSM on often causes the guest to hang at a black screen on first boot.

6. Set PCIe slot to Gen4 or Gen5 as appropriate. Avoid “Auto” if your board offers per-port generation control; pinning the target slot to a fixed generation reduces link-training stalls inside the VM.

7. Enable SR-IOV support if you plan to use vGPU (Grid). Not needed for plain PCI passthrough, only for vGPU/MIG-style splitting.

Reboot, enter BIOS again just to confirm the settings stuck, then boot into Proxmox. Many boards silently revert certain options after a firmware update, so this second check is worth the 60 seconds.

Enabling IOMMU in the Proxmox Kernel

Enabling IOMMU requires passing kernel command line parameters. Proxmox VE 9 uses two distinct boot paths depending on whether you installed to EXT4 with the legacy BIOS GRUB, or to ZFS with the new Proxmox-boot-tool. Get this wrong and your changes will appear to save but never take effect.

If you installed Proxmox with the default EXT4 layout on a system without UEFI, your kernel command line is managed by GRUB. Edit /etc/default/grub and find the GRUB_CMDLINE_LINUX_DEFAULT line.

For Intel CPUs add intel_iommu=on iommu=pt. For AMD CPUs add amd_iommu=on iommu=pt. The iommu=pt flag enables pass-through mode, which is what you want for GPU passthrough instead of the default translation mode.

Example for an Intel system on EXT4:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

Save the file, then run update-grub and proxmox-boot-tool refresh if you also have a UEFI entry. Reboot to load the new parameters.

If you installed Proxmox VE 9 with ZFS or with UEFI, the kernel command line lives in /etc/kernel/cmdline, not /etc/default/grub. Editing GRUB on a ZFS install will leave you staring at unchanged parameters even after update-grub completes. This is the single most common cause of “IOMMU still shows disabled after reboot” on Proxmox 8.x and 9.x.

Append your IOMMU flags to /etc/kernel/cmdline on a single line, separated by spaces. Then run proxmox-boot-tool refresh followed by update-initramfs -u -k all and reboot.

One useful note for 2026: if you are running kernel 6.8 or newer (the default in Proxmox VE 9), intel_iommu=on and amd_iommu=on are no longer strictly necessary. The kernel enables IOMMU automatically when it detects the hardware. iommu=pt still helps because it switches the driver to pass-through mode. I still add the explicit on flags in my own hosts because it documents intent and survives kernel downgrades.

After reboot, confirm the parameters actually loaded by running cat /proc/cmdline. If your flags are missing, you almost certainly edited the wrong file for your boot method.

Configuring VFIO Modules

Once IOMMU is active at the kernel level, you need to load the VFIO (Virtual Function I/O) modules so the kernel can actually present a PCI device to a guest. VFIO is the modern, secure replacement for the older KVM device assignment and is what Proxmox uses under the hood.

Create /etc/modules entries for the modules you want loaded at boot:

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

These four modules cover everything required for a typical GPU passthrough. vfio_iommu_type1 is the core IOMMU API driver, vfio_pci binds PCI devices, and vfio_virqfd handles fast interrupt forwarding. You can leave them in /etc/modules permanently; they only consume a few kilobytes each.

Next, tell vfio-pci which devices to grab on boot. Find the vendor and device IDs of your GPU with lspci -n -s $(lspci | awk '/NVIDIA/{print $1; exit}') for NVIDIA, or adjust the awk pattern for AMD.

The output will look like:

01:00.0 0300: 10de:2484 (rev a1)
01:00.1 0403: 10de:228b (rev a1)

Note the eight-character 10de:2484 and 10de:228b strings. The first line is the GPU, the second is the HDMI audio controller sitting on the same card. Put both into /etc/modprobe.d/vfio.conf:

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

If you have a second GPU (a Quadro or a second Radeon for a separate VM), append its IDs here too. The vfio-pci module silently ignores unknown IDs, so extra entries never hurt.

Reboot once more so the modules load in the right order and claim the GPU before the host display drivers do. After this reboot the GPU should no longer appear as a usable display adapter to the Proxmox host.

Blacklisting Host GPU Drivers

Even with vfio-pci configured, the host kernel will race to bind the GPU to its own display driver (nouveau, nvidia, amdgpu, or radeon). If the host wins that race, VFIO cannot take the device back without a full unload. Blacklisting the host drivers ensures VFIO always wins.

For NVIDIA cards, blacklist both nouveau (the open driver) and nvidia (the proprietary driver) so the GPU stays unbound:

cat /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
blacklist lbm-nouveau
options nouveau modeset=0

cat /etc/modprobe.d/blacklist-nvidia.conf
blacklist nvidia
blacklist nvidiafb
blacklist nvidia_drm
blacklist nvidia_modeset

For AMD cards, blacklist both amdgpu and radeon to be safe. Modern RDNA2/3/4 cards use amdgpu exclusively, but radeon still triggers on some legacy firmware paths.

cat /etc/modprobe.d/blacklist-amdgpu.conf
blacklist amdgpu
blacklist radeon

For the AMD RDNA3/RDNA4 fix specific to Proxmox 9, you must also disable framebuffer console binding on the GPU. Create /etc/modprobe.d/amdgpu-disable.conf with options amdgpu si_support=1 cik_support=1 removed and instead add options amdgpu si_support=0 cik_support=0 runpm=0. The runpm=0 flag stops amdgpu from putting the card into a power state that confuses the IOMMU remapping tables on first passthrough.

Run update-initramfs -u -k all after any blacklist change, then reboot. This regenerates the initial ramdisk so the blacklisted drivers never load even during early boot.

Verifying IOMMU and Checking IOMMU Groups

Before you start editing VM configs, prove that IOMMU actually works. There is no point chasing phantom errors in QEMU if the kernel never enabled IOMMU in the first place.

Run dmesg | grep -e DMAR -e IOMMU. On Intel you want lines containing “DMAR” and “IOMMU enabled”. On AMD you want lines with “AMD-Vi” and “IOMMU enabled”. If you see nothing, your kernel parameters never loaded, re-check Step 3.

A good Intel output looks like:

[ 0.000000] DMAR: IOMMU enabled
[ 0.123456] DMAR: dmar0 hardware IOMMU context

A good AMD output looks like:

[ 0.000000] AMD-Vi: IOMMU performance counters supported
[ 0.123456] AMD-Vi: IOMMU enabled

Next check that interrupt remapping is also active. PCI passthrough without interrupt remapping is unreliable on most chipsets. Look for:

dmesg | grep -i 'remapping'

On Intel you should see “Interrupt remapping enabled”. On AMD you should see “IRQ remapping enabled”. If interrupt remapping is missing, add intremap=atlon (Intel workaround) to your kernel cmdline, or update your BIOS if the vendor left it disabled behind a hidden flag.

Finally, check IOMMU group isolation. This is the step most beginners skip and then wonder why their VM hangs or reboots the host. The community has a well-known shell snippet you can drop into /usr/sbin/iommu-check.sh:

#!/bin/bash
for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*/devices/}
  echo "IOMMU Group $(echo $d | cut -f4 -d/) $(${d%/*}/../../name 2>/dev/null): $(lspci -nns ${n##*/} 2>/dev/null)"
done

Run it with bash iommu-check.sh. The output lists every PCI device on the host along with its IOMMU group number. Your GPU should sit in a group that contains nothing else important (other than the GPU’s own audio function). If your GPU is grouped with SATA controllers, USB controllers, or network cards, every device in that group must be passed through together, which usually breaks the VM.

If the grouping is bad, you have three options. The simplest is to move the GPU to a different physical PCIe slot. Most x16 slots on consumer boards get their own IOMMU group, while the bottom x1 slots share groups with everything else. The second option is to enable pcie_acs_override, which I will explain in the troubleshooting section. The third option is to accept the limitation and pass the entire group through, which often works for full-desktop Windows gaming VMs because you do not need the host’s SATA controller.

Preparing the VM for GPU Passthrough

With the host fully configured, you can now build the VM. The VM hardware choices below are not optional. Each one enables a specific feature the guest OS needs to drive a physical GPU at full speed.

Create or open the VM in the Proxmox web UI. Then change the following settings on the “Hardware” tab:

Set the Machine type to q35. The older i440fx machine type lacks PCIe root complex features that modern GPUs and Windows 10/11 driver stacks expect. q35 emulates a real PCIe topology with proper ACS, AER, and ECN features.

Set the BIOS to OVMF (UEFI). SeaBIOS still works for some Linux guests, but Windows 10 and 11 will not install GPU drivers cleanly without UEFI. To switch to OVMF you also need to add an EFI Disk on the same screen; Proxmox will create a small 128 KB EFI partition for you.

On the “Options” tab, set “CPU type” to host. This exposes every CPU feature flag (including hidden flags like pcid and invtsc) to the guest. For gaming VMs where frame timing matters, leaving CPU type on kvm64 introduces measurable stutter. If you need to live-migrate between hosts with different CPUs, use a named CPU type instead.

Also on “Options” tab, enable “kvm_pv_unhalt” and consider enabling “hpet”, “ballooning”, and “freeze” features. These small flags reduce jitter inside the VM and improve frame pacing on Windows guests.

On “Processors” tab, set the core and socket count to match your physical allocation. For an 8-core host dedicated to one Windows gaming VM, sockets=1 cores=8 is the usual starting point.

Finally, attach a virtual disk, your Windows or Linux ISO, and your VirtIO driver ISO if applicable. Do this before adding the GPU so you can install the OS in a software-rendered mode before the real GPU takes over.

Adding the GPU to the VM

This is the moment everything comes together. On the Proxmox VM “Hardware” tab click “Add” then “PCI Device”. Pick the GPU’s primary function (the one with class 0300, the VGA controller). Leave “All Functions” enabled if you want the HDMI audio controller passed through too, which is the typical setup for a real monitor plugged into the GPU.

The “PCI Express” radio button should be checked. “Legacy” PCI is only for ancient devices and will not work on a modern GPU.

Check the “Primary GPU” box only if this VM is the only thing that ever sees the GPU. If you plan to hot-swap or move the card between VMs, leave “Primary GPU” off and use x-vga=0 in the config file.

After clicking Add, switch to the Proxmox shell and open /etc/pve/qemu-server/<vmid>.conf. Find the newly added hostpci0 line and append ,x-vga=1 if you want this VM to own the GPU exclusively at boot. For modern systems the default already includes the equivalent option.

A complete hostpci0 line for an NVIDIA card with audio passthrough looks like:

hostpci0: 01:00,pcie=1,x-vga=1,multifunction=on

The multifunction=on flag tells the guest that the GPU and its sibling audio function are part of the same multifunction device, which is how real GPUs appear physically. Without it, Windows sometimes initializes the audio function as a separate phantom device.

If your GPU refuses to initialize in the VM with a “BAR 3: can’t reserve” error, you need to dump the vBIOS and point Proxmox at it. Run echo 1 > /sys/bus/pci/devices/0000:01:00.0/rom then cd /usr/share/kvm && cat 0000:01:00.0 > gpu.rom. Reference the file in your config with romfile=gpu.rom appended to the hostpci0 line.

For NVIDIA cards, you may also need to patch the dumped vBIOS to remove the UEFI disable check. The community uses rom-parser for inspection and the alternate vbios-ampere-mod for Ada and Hopper cards. Most RTX 30 and 40 series work without any patching when UEFI GOP is present, so try the unpatched file first.

Installing GPU Drivers in the Guest OS

Boot the VM. First boot happens on the emulated QXL/VirtIO display, which gives you a window to install the OS. Install Windows with the VirtIO drivers from the virtio-win-xxx.iso, and add the vIOSCSI disk controller plus the balloon service before the first reboot.

After the OS is fully booted and updated, shut the VM back down, switch the Proxmox “Display” option to “None” (not “Standard VGA” because the latter will keep the emulated adapter around), and reboot. The VM should now display through the physical GPU connected to your monitor.

Install the GPU driver. For NVIDIA, run the standard GeForce or Quadro installer. Make sure you are using a driver from 2026 or later, because older drivers may not know about PCIe atomic operations on AMD Ryzen hosts.

For AMD, use the AMD Adrenalin installer and pick “Clean Install” if you are switching cards or driver branches. RDNA3 and RDNA4 cards (RX 7000 and 9000 series) need at least Adrenalin 2026 for stable passthrough on Proxmox 9; older drivers may trigger Code 43 on first VM reboot.

If you see Code 43 in Device Manager after driver install, jump straight to the troubleshooting section. Code 43 almost always means the GPU was passed through with hidden state that the driver detected, and there are well-known fixes for both vendors.

Troubleshooting Common Issues

Most GPU passthrough failures fall into a small number of buckets. I will walk through the four issues I see most often on the Proxmox forum and Reddit.

Error 43 in Windows guest. This means the NVIDIA driver decided the device is in a virtual machine and refused to load. On Proxmox 9 with QEMU 9.x, this is almost always fixed by hiding KVM’s CPUID bits. Add a CPU flag in /etc/pve/qemu-server/<vmid>.conf:

cpu: host,hidden=1,flags=+hv-fvendor

This hides the hypervisor bit from the guest CPU and makes the driver think it is running on bare metal. AMD GPUs are not affected by Error 43 and will work without the hidden flag.

Host freezes during VM start. This points to bad IOMMU grouping on consumer motherboards, especially B550 and X570 boards. Confirm the GPU’s IOMMU group with the script from Step 6. If the GPU shares a group with the SATA controller, either move the card or add pcie_acs_override=downstream,multifunction=no to the kernel cmdline. Note that pcie_acs_override breaks the platform’s IOMMU isolation guarantees, so only use it when you understand the security trade-off. Always try a different PCIe slot first.

AMD reset bug. Some older AMD cards (pre-RDNA) cannot reset their internal state cleanly between VM reboots. If the host hangs when you stop the VM, or if the second VM start fails with “vfio-pci: device is busy”, you need a vendor-reset patch. The community maintains vendor-reset as an out-of-tree DKMS module. RDNA and newer are unaffected.

BAR 0 is 0M error / BAR 3: can’t reserve. The GPU’s video BIOS exposes a BAR the guest cannot map because of how Proxmox exposes the BAR to the VM. The fix is almost always to dump the vBIOS, add romfile=gpu.rom to hostpci0, and reboot. Second option is to enable Above 4G Decoding in BIOS, which the BIOS checklist already covered, but if it is not enough, dump the vBIOS.

For more detailed diagnosis, the Proxmox wiki’s PCI Passthrough page has an exhaustive troubleshooting list updated by the community. Always cross-reference the wiki when something does not match my instructions, because the wiki gets faster updates than any single guide.

Frequently Asked Questions

Conclusion

You now have a working GPU passthrough setup on Proxmox VE 9. The path is identical in spirit to what has worked since Proxmox 6, but the ZFS bootloader, kernel 6.8+ defaults, and the AMD RDNA3/RDNA4 BIOS quirk are what trip people up in 2026.

From here the natural next steps are to benchmark the GPU inside the VM, tune CPU pinning and NUMA topology for gaming latency, or build a second VM and pass a second GPU to it. If you run into a problem not covered here, the Proxmox forum’s GPU passthrough section is the most active community space for this specific topic.