# GPU passthrough to a Windows VM: what it can and cannot measure

> Plan a PVE GPU passthrough Windows VM, understand IOMMU/vfio/vBIOS issues, and separate VM results from bare-metal performance.

**Tested on**

- Build: 26300.9457
- Edition: Pro (26H2)
- Architecture: x64
- Evidence: E1
- Verified: 2026-10-28

## The short answer

GPU passthrough gives a VM a real GPU via VFIO. It is excellent for **testing drivers, UI, tuning and many games**. It is **not** a bare-metal benchmark machine:

- CPU overhead and VM exits remain;
- display path/capture can add latency;
- some anti-cheat and DRM refuse a VM;
- vendor drivers may detect/limit virtualisation;
- single-GPU hosts need special handling.

Use VM results as **M-V**, not as an absolute FPS claim.

## What you need

| Requirement | Why |
|---|---|
| IOMMU enabled (VT-d/AMD-Vi) | Isolates the GPU |
| ACS / clean IOMMU groups | The GPU must be isolated from the host |
| vfio-pci binding | Host must not claim the GPU |
| GPU vBIOS / reset support | Some cards need a ROM or reset workaround |
| Second GPU or iGPU | Host needs a display if the GPU is passed through |
| PVE hostpci config | Attach the device to the VM |
| Windows VM (q35/OVMF) | Matching the GPU driver stack |

## Outline

1. Enable IOMMU in firmware and the kernel command line.
2. Confirm IOMMU groups: `find /sys/kernel/iommu_groups/ -type l`.
3. Blacklist the host driver and bind `vfio-pci` to the GPU/audio function.
4. Add the PCI device to the VM (`hostpci0`), with PCIe/ROM options as needed.
5. Install the vendor driver in Windows.
6. Verify with Device Manager and `nvidia-smi`/Adrenalin/Arc Control.
7. Test a known workload and record the VM configuration.

Do not copy a hostpci line from a forum without checking your IOMMU group and device IDs. Passing the GPU without its audio function or with the wrong ROM can produce a black screen.

## What can be measured

| Question | VM result useful? | Caveat |
|---|---|---|
| Does the driver install? | Yes | Driver may behave differently in a VM |
| Does the game launch? | Yes | Anti-cheat may block |
| Relative driver/setting changes | Yes, with M-V label | Same VM, same host |
| Absolute FPS vs bare metal | No, not directly | CPU/VM overhead, display path |
| Latency | Careful | Capture/display adds error |
| Battery/thermal | No | Not representative |

## Anti-cheat and licensing

Some anti-cheat systems treat a VM as an untrusted environment. Some NVIDIA/AMD driver features or licensing terms restrict virtualisation. Check the vendor and game terms; do not try to hide the VM from anti-cheat.

> **Caution: No GPU passthrough in this lab**
>
> Our PVE VM 361 has no GPU passthrough. This page is **E1** guidance; we have not produced an M-V GPU result. Do not read it as a benchmark.

## Safer test design

- Use a second GPU for the host, or a headless host with IPMI/serial.
- Keep a known-good snapshot before changing vfio/hostpci.
- Record the exact host GPU, vBIOS, PVE version and VM config.
- Compare only runs on the same VM and host.
- If a result matters for a buying decision, validate on physical hardware.

## Sources

- [Proxmox VE — PCI passthrough](https://pve.proxmox.com/wiki/PCI_Passthrough)
- [Proxmox VE — Windows 11 guest best practices](https://pve.proxmox.com/wiki/Windows_11_guest_best_practices)
- [NVIDIA — virtualization support](https://www.nvidia.com/en-us/data-center/virtualization/)

---

Source: https://winbook.fyi/en/windows/dev/gpu-passthrough/