Handing my only GPU to a VM, and getting it back

I have one GPU. The question I wanted answered: can I hand it to a Windows VM on demand and take it back when I close the VM, with no dual-boot and no second machine?

A friend runs this setup so he can play the handful of games that refuse to touch Linux. For me it was an experiment - does single-GPU passthrough actually hold up as a daily-usable thing, or is it a party trick?

Short answer: it works, and it costs you your whole desktop session every single time.

What "handing it over" means#

VFIO is the kernel subsystem that does it. It rips a PCI device off its normal driver (nvidia or amdgpu), hands the raw device to userspace, and lets QEMU drive it directly. The guest sees a real GPU.

Linux desktop owns GPU
       |
       |  start VM:  kill session, unbind driver, bind vfio-pci
       v
Windows VM owns GPU      <-- your Linux session no longer exists
       |
       |  stop VM:    unbind vfio, reload driver, restart sddm
       v
Linux desktop owns GPU   <-- fresh session, the old one is gone

The startup side, step by step:

1. Inhibit host sleep so the screen does not blank mid-transition.
2. Stop the display manager.
3. Unbind the virtual terminals from the GPU framebuffer.
4. Unbind the firmware framebuffer (simpledrm on new kernels, efifb on old ones).
5. Unload the driver stack (nvidia, nvidia_modeset, nvidia_drm, nvidia_uvm, or amdgpu).
6. Bind the GPU's PCI BDFs to vfio-pci.
7. Pin the host to a few housekeeping cores with cgroup v2.
8. Free host RAM: drop caches, SIGSTOP the heavy processes so their memory stays put but stops fighting the guest.
9. Allocate 2M transparent hugepages for the guest.
10. Start QEMU.

Shutdown is every step in reverse. libvirt runs a hook script per transition. About 200 lines if you are honest, three times that once you want it to survive a step failing halfway.

You do not get your session back#

The display manager (sddm here) gets killed and restarted, so X or the compositor comes back. The session inside it does not.

Plasma restores window geometry when an app launches into the NEXT session. It does not restore a live session that lost its compositor mid-air. What survives is whatever saves its own state:

• Firefox tabs, because Firefox saves them
• Kate buffers, because Kate saves them
• tmux, separate daemon, never knew anything happened

What dies with the session:

• pinned terminal positions on virtual desktops
• unsaved files in anything without autosave
• clipboard history, klipper dies with the session
• Bluetooth devices paired against the old session
• custom kwin rules and workspace layout

So you save everything before you hit Start VM. I found that out by not doing it.

Three layouts, honest comparison#

After months of running it, there are three ways to do this and they are not equal:

Single GPU: one card does desktop and VM, so it gets ripped away on every launch. Only worth it if you physically have one slot.

iGPU + dGPU: a Ryzen G-series APU or non-F Intel chip drives the desktop on the integrated GPU, the discrete card sits idle until a VM grabs it. Cheap, desktop survives. Downside: the iGPU is now your only GPU on Linux. Fine for desktop and code. Not for rendering, training, or gaming on Linux.

Two discrete GPUs: one card stays bound to Linux and does real work, the other is handed to vfio-pci at boot and lives only for the VM. Your desktop survives, Linux keeps a real GPU, and because the VM card never hands back you sidestep the reset bug entirely - which also means the otherwise-risky cards (RTX 50, RX 7000) are fine in this slot. The cost is a whole second card, a slot, and the PSU and airflow to feed it.

So the pick depends on one question: do you do GPU-heavy work on Linux? If no, iGPU + dGPU is the cheap clean answer. If yes, two discrete cards with one pinned to the VM. Single-GPU is the answer only when one slot is a constraint you cannot move.

The reset bugs#

Two GPU families have a function-level reset bug that only bites passthrough. After the VM shuts down the card is in a state the host driver cannot re-grab, so you reboot the host to get the GPU back on Linux.

• RTX 50 (Blackwell): NVIDIA confirmed it. One VM run per host boot, no clean workaround.
• RX 7000 (RDNA3): AMD does not officially support passthrough on the 7900 XTX, and reset is broken. vendor-reset patches some 6000-series cards, not 7000.

Both are fine in a two-GPU host where the dGPU never goes back to Linux. They break the single-GPU hand-back, and only that. Buying for passthrough in 2026: RTX 30/40 and RX 6000/9000 are the safe brackets. Avoid RTX 50 unless rebooting after every VM is fine with you.

Where I landed#

I do not run single-GPU passthrough. The experiment proved the mechanics work, but my card does real GPU work on Linux, so an iGPU desktop was never on the table, and the two things that killed it for daily use were losing the session on every launch and the RX 7000 reset bug on my own card. If I needed a Windows VM often enough to justify it, I would put in a second discrete card dedicated to the VM and never hand it back.

Full writeup, copy-paste grade: Single-GPU Passthrough on Linux.