A man around Linux

GPU passthrough on KVM gives a virtual machine direct ownership of a physical PCIe graphics device instead of presenting an emulated adapter. The guest loads the native vendor driver, controls the GPU memory, and submits work with near-native device access. This model suits CUDA or ROCm workloads, rendering, workstation virtualization, and applications that require a real display controller. The hard part is not adding a PCI address to a VM definition. A reliable deployment depends on firmware configuration, interrupt remapping, correct IOMMU grouping, early driver binding, guest firmware, PCIe topology, and predictable device reset behavior. A GPU may also expose separate audio, USB, or serial functions that belong to the same physical card. Passing only the display function can produce a VM that starts once, fails after shutdown, or leaves part of the device attached to the host. This guide assumes a Linux host running KVM, QEMU, libvirt, VFIO, and an OVMF-based guest. Commands use D...

  A GPU passthrough KVM setup assigns a physical PCIe graphics device directly to one virtual machine through VFIO. The guest uses the vendor driver and accesses the card with much less virtualization overhead than an emulated or paravirtualized display. This is useful for CUDA workloads, rendering, remote workstations, machine learning, and applications that require native driver capabilities. The difficult part is not adding a PCI address to a VM definition. Reliable passthrough depends on firmware settings, IOMMU topology, early driver binding, guest firmware, reset behavior, and a rollback path. A configuration can boot successfully and still be operationally weak if the host occasionally claims the GPU, if another device shares its isolation group, or if the VM cannot recover after a guest reboot. This guide targets Debian and Ubuntu hosts running KVM, QEMU, and libvirt. The same principles apply to other distributions, but bootloader, initramfs, and package commands may diffe...

A GPU passthrough KVM setup assigns a physical PCIe graphics device directly to a virtual machine through VFIO. The guest loads the native vendor driver and controls the GPU with far less virtualization overhead than an emulated display. The hard part is not adding a PCI address. It is proving that firmware, PCIe topology, kernel driver ownership, DMA isolation, reset behavior, and guest firmware all agree on the assignment. This guide assumes you already administer Linux virtualization hosts and understand KVM, QEMU, libvirt, initramfs, and PCI addressing. The workflow targets a dedicated host with console or out-of-band access. Do not perform the first reboot remotely without a recovery path, especially when the selected GPU is also the host boot display. The safest design uses a GPU that the host never needs, an isolated IOMMU group, a Q35 machine type, OVMF UEFI, and explicit assignment of every required PCI function. Before changing boot parameters, record the current kernel comma...