GPU passthrough is a virtualization technique in which a physical graphics card is assigned exclusively to one virtual machine, so the guest operating system loads its own native driver and talks to the hardware directly. On Linux it is implemented with KVM, QEMU and the VFIO framework, which hands a PCI Express device to a guest while the IOMMU keeps the device’s memory access confined to that guest.
The result is near-native graphics and compute performance, typically within a few percent of bare metal, which makes GPU passthrough the standard way to run games, CAD software, video encoding or machine learning workloads inside a virtual machine. The trade-off is that the card becomes unavailable to the host and to every other guest while it is assigned.
How GPU passthrough works on Linux
A graphics card is an ordinary PCI Express device with its own configuration space, memory-mapped registers (BARs) and the ability to read and write system memory through direct memory access. Passthrough requires that the guest can program the card as if it were real hardware, without being able to corrupt memory that belongs to the host.
The IOMMU, called Intel VT-d or AMD-Vi, solves this by translating the addresses a device uses for DMA. The host builds a translation table that maps guest-physical addresses to the host pages backing the virtual machine. The vfio-pci driver binds to the GPU instead of the normal host driver and exposes it to QEMU, which maps the BARs into the guest and routes interrupts through posted interrupts or eventfd.
The components involved and their roles are summarized below.
| Component | Role | Typical configuration |
|---|---|---|
| IOMMU | Isolates device DMA per guest | intel_iommu=on or amd_iommu=on, iommu=pt |
| vfio-pci | Claims the GPU for user space | vfio-pci.ids=10de:xxxx,10de:yyyy |
| KVM | Hardware-assisted CPU virtualization | Loaded as kvm_intel or kvm_amd |
| QEMU | Emulates the machine, maps the device | Q35 chipset with OVMF firmware |
| libvirt | Manages the guest definition | hostdev entry with managed=’yes’ |
Hardware and firmware requirements
GPU passthrough depends far more on the platform and firmware than on the Linux distribution. The CPU and chipset must support an IOMMU, the firmware must enable it, and the motherboard must place the GPU in a clean IOMMU group, because every device in a group must be passed to the same guest.
| Requirement | Why it matters | How to verify |
|---|---|---|
| VT-d or AMD-Vi enabled | No IOMMU means no safe DMA isolation | dmesg shows DMAR or AMD-Vi messages |
| Isolated IOMMU group | Group members must move together | List /sys/kernel/iommu_groups |
| UEFI-capable GPU firmware | Required for OVMF guests | Card boots with UEFI GOP |
| Second GPU or iGPU for host | Host needs its own display | Separate card or integrated graphics |
| Interrupt remapping | Prevents interrupt injection attacks | dmesg reports remapping enabled |
The ACS override patch can split a poorly grouped slot into separate groups, but it only tells the kernel to assume isolation that the hardware may not provide. It weakens the security guarantee and should be treated as a workaround for home labs, not a production setting.
Passthrough compared with other GPU sharing models
Full passthrough is only one way to give a virtual machine graphics acceleration. The alternatives trade performance for density or flexibility, and the right choice depends on how many guests need the GPU at the same time.
| Approach | Guests per GPU | Performance and limits |
|---|---|---|
| Full passthrough (VFIO) | One | Near-native; host loses the card |
| SR-IOV virtual functions | Several, fixed slices | Near-native per slice; needs card and driver support |
| Mediated devices (vGPU, GVT-g) | Several, time-sliced | Good; often licensed or hardware-specific |
| Virtio-GPU with VirGL or Venus | Many | Paravirtualized; lower and API-dependent |
| Emulated display (QXL, VGA) | Many | No 3D acceleration; desktop use only |
Neighboring tools in Linux virtualization play distinct roles: VFIO is the kernel interface, QEMU performs the device mapping, libvirt and virt-manager store the configuration, and Proxmox VE wraps the same mechanisms in a web interface. Containers such as LXC or Incus do not need passthrough at all, because they can share the host’s GPU driver directly.
Configuring and tuning a passthrough guest
A reliable setup starts by binding the GPU and its audio function to vfio-pci early in boot, before the host driver can claim them, usually through kernel parameters or a modprobe configuration in the initramfs. The guest is then defined with the Q35 machine type, OVMF UEFI firmware and both PCI functions attached.
Performance depends heavily on the rest of the guest configuration. The following decisions have the largest effect.
| Setting | Recommended choice | Reason |
|---|---|---|
| CPU pinning | Pin vCPUs to dedicated cores | Reduces latency and frame-time spikes |
| CPU model | host-passthrough | Exposes full instruction set to the guest |
| Memory backing | Hugepages, 2 MB or 1 GB | Fewer TLB misses, faster DMA mapping |
| Disk and network | Virtio drivers or NVMe passthrough | Avoids emulation overhead |
| Display output | Physical monitor or Looking Glass | Low-latency frame delivery |
Resizable BAR support, correct NUMA placement on multi-socket hosts and disabling unnecessary emulated devices bring the remaining gap to bare metal down further.
Pitfalls and common failure modes
- Reset bugs: some cards do not reset cleanly when the guest shuts down, so the second boot hangs until the host reboots.
- Host driver grabbing the card: if amdgpu, nouveau or nvidia binds first, vfio-pci cannot claim it.
- Error 43 on older NVIDIA drivers: consumer drivers once refused to run in a detected VM; current drivers allow passthrough.
- Anti-cheat software in some games blocks or flags virtual machines regardless of performance.
- Shared IOMMU groups force passing through unrelated devices such as USB or SATA controllers.
A disciplined approach is to verify each layer separately: IOMMU active, group isolated, vfio-pci bound, guest firmware booting, and only then driver installation inside the guest.
A plain-language summary
A virtual machine is a computer that lives inside another computer as software. Normally it gets a pretend graphics card, which is fine for office work but far too slow for games or video editing. GPU passthrough unplugs a real graphics card from the main computer in software and plugs it into the virtual one.
The virtual computer then uses the card as if it were sitting in its own case, at almost full speed. The catch is that only one machine can use that card at a time, so the host usually keeps a second, simpler graphics chip for itself.
An example from practice
An engineering firm runs Linux workstations but depends on a Windows-only CAD package for one client. Instead of dual-booting, each workstation gets a second graphics card. The integrated graphics drive the Linux desktop, while the dedicated card is bound to vfio-pci and assigned to a Windows guest with 8 pinned cores, 32 GB of hugepage-backed memory and an NVMe drive passed through.
Benchmark runs inside the guest land within about five percent of a native Windows installation, and engineers switch between Linux tools and the CAD package without rebooting. Snapshots of the guest disk make it possible to roll back a failed CAD update in minutes, which had previously meant a full reinstall.