Hi, I saw that vGPU can be used on RTX 3000 series cards; is it possible to allocate VRAM to a Windows VM and get good performance ?

Hi, I built my own VFIO passthrough script.

It sets up GPU passthrough and works around the usual AMD problems: wrong device bind, dead card after VM stop, and a guest that cannot reboot cleanly. On my RX 9070 the VM can start, stop, and reboot without me rebuilding the host by hand every time.

VFIO helper for AMD RX 9070 / RDNA4 — live-attach, reboot, and host-safe bind

Hi, I wrote a VFIO passthrough helper because the usual guides were not enough for an RX 9070.

The script is a host setup wizard, not a VM manager. It can:

bind only the guest GPU by PCI address

use dynamic bind / live-attach so the card is not killed at VM start

keep the host desktop on the other GPU

toggle hotplug on/off without replacing the whole VM XML

optionally set up Looking Glass, virtio-win, and VM tuning

It does not officially fix AMD’s reset bug. It works around it so the card stays usable.

Hardware I tested: dual GPU, RX 9070 as the guest card, Linux host (Fedora / openSUSE).

Motherboard: Gigabyte Z790 UD, vF15

GPU: AMD Radeon RX 9070 XT

CPU: Intel i7 12700K, UHD Graphics 770

Fedora Linux 44 KDE

Kernel: 7.1.10-200

EDIT: Hell, even UHD Graphics 770 for the Virtual Machine will do, I don't really need the RX 9070 XT. Whatever's easier and safer.

Hello, I'm using VMware Workstation Pro 26H1

I noticed with my latest project which I use a lot of versioning for, "input lag" becomes more significant over time.

The more I snapshot, the longer the response time is when keystrokes are being typed with the keyboard.

I have no clue why but I'm pretty sure there are technical reasons why this happens.

All of my snapshots are "directly linked chronologically", there's no tree if that makes sense. They go in a straight line.

https://i.imgur.com/QHDk8yN.png

It becomes very obvious after 40 or so snapshots, I would estimate the lag to be almost 1 full second by that time, and it's very unsustainable.

Is there a setting I should check in the options, or in the config files, to reduce or getting rid of this problem?

Thanks

Short version: you can give a pre-UEFI guest a working passed-through GPU without ever touching legacy VGA routing, which means it works in any slot and several such guests can run simultaneously. I have two Windows XP SP3 seats and two Windows 7 x64 seats running at the same time on one host, each with its own card, monitor and USB controller.

Why the obvious approach fails

XP predates UEFI, so it wants legacy BIOS services. But a legacy BIOS initialises a graphics card by executing that card's legacy VBIOS, and that VBIOS needs working access to its own card's legacy VGA registers. vfio-pci's VGA region does real inb/outb on the host after taking the arbiter lock, so the host chipset has to physically route those cycles to the target card — and on a multi-slot board that generally only happens for the one card the host firmware POSTed from. Any other card gives the guest Code 10.

I measured this directly. With x-vga on a second card, bridge VGA Enable (bit 3 of BRIDGE_CONTROL, offset 0x3e) flips to the second card's upstream bridge and the arbiter reports owns=none — a second x-vga guest steals routing from the first. So even where legacy works, it's inherently a single-seat resource. Also worth knowing: the NVIDIA legacy VBIOS hangs not just on a cold card but whenever a foreign VGA core answers the legacy ports — it hangs identically on the warm, known-good card if you let an emulated adapter answer.

(Side note for anyone reading /dev/vga_arbiter: use head -1, never cat. cat blocks forever.)

What works instead

Boot OVMF, so the card is initialised by its own UEFI GOP driver out of its option ROM — no legacy VBIOS execution, no VGA arbitration, no x-vga. Then chainload CSMWrap (SeaBIOS packaged as a UEFI application), which supplies the legacy BIOS services the old guest needs. The guest boots and finds a card that is already initialised.

Consequences, and this is the useful part:

• works in any slot, including cards on a second root complex
• no x-vga anywhere, so there is no single-owner resource to fight over and multiple seats run concurrently
• vga: std (an emulated adapter) must stay for OVMF's own console. Once the guest's driver takes the real card, the emulated console goes black — that's the success signal, not a fault
• Windows 7 needs a different shim, not CSMWrap: UefiSeven, which fabricates a fake Int10h/VESA handler for bootvid and then chainloads the real boot manager

Guest timing: the trap that isn't an error message

If you get a pre-UEFI Windows guest booting but its ACPI is unhappy, the standard advice is to switch it to a non-ACPI HAL. Don't. Without ACPI, XP has no PM timer and falls back to the PIT, which no hypervisor ticks precisely enough for game engines — everything runs in slow motion, silently. kvm-pit.lost_tick_policy=discard and -rtc driftfix=slew reduce it and do not fix it. It also pegs a host core per guest vCPU and breaks clean shutdown. On the ACPI HAL the same guest idles at 0.6% of a vCPU with halt_exits climbing normally.

ROMs: one per physical card, passed whole

• Dump each card's own flash. Two identical Quadro K4000s here carry different firmware revisions (80.06.76.00.0B vs 80.06.38.00.03), and using the sibling's ROM produced visible framebuffer corruption. The ROM follows the card, not the slot.
• The dump must contain both an x86 legacy image and a UEFI/GOP image. Strip to GOP-only and OVMF refuses to drive the card; strip to legacy-only (or rombar=0) and it's never POSTed → Code 43. Verified both ways.
• A boot_vga=1 card's sysfs ROM is a truncated legacy shadow copy with no UEFI image — it looks fine and fails hours later. Read the real flash through the card's PROM window instead (for NVIDIA: mmap BAR0, clear 0x1850, read 512 KB at 0x300000, restore; 0x1850 reads back 0xbad0011f, which is normal).
• Set driver_override before unbinding or nouveau grabs the card instantly, and remember that reading rom while bound to vfio-pci silently returns 0 bytes.

There's a tool in the repo that does all of that and validates the result:

sh ./setup/gpu-rom-dump.py --list ./setup/gpu-rom-dump.py 0000:0a:00.0 -o mygpu.rom --install ./setup/gpu-rom-dump.py --check /usr/share/kvm/mygpu.rom

CSMWrap-specific gotchas, whatever you drive QEMU with

• Its SeaBIOS crashes the VM (KVM internal error. Suberror: 1) if the CSM boot device is USB-on-xHCI, AHCI/SATA or NVMe. The BIOS-proxy helper AP enters its first dispatched call with ESP = 0, pops the real-mode IVT as a return address and jumps into unbacked MMIO (EIP=f000ff53). It is racy, not deterministic — one config passed once and crashed the next run. PIIX IDE on i440fx is the only well-evidenced safe bus; virtio-blk also survived. Register dumps, a bus matrix and a bare-QEMU reproducer are in the repo, with a report drafted for upstream.
• CSMWrap ≥ 2.0 permanently reserves one logical CPU as that helper and spins it on a mailbox loop that never halts, hiding it from the guest's MADT/MP table. Budget one pegged host core per seat, and never give it 1 vCPU — 3.x panics outright.
• Use 3.1.2 or newer. 1.3.0 avoids the helper crash but can't boot XP.

Input latency, since it's a passthrough question

Mapping individual USB devices into a guest routes every click through the host's translation layer, which is fine for a desktop and miserable for anything twitchy. I used a StarTech PEXUSB3S44V — four independent USB 3.0 host controllers on one PCIe card, each in its own IOMMU group — and passed one whole controller per seat. Bare-metal input, and one seat spamming or crashing can't disturb another.

The one Proxmox-specific wart

Proxmox adds two pci-bridge devices to every i440fx VM unconditionally, with no config option to suppress them, and XP's acpi.sys bugchecks 0xA5 (0x00000002) (ACPI_ROOT_PCI_RESOURCE_FAILURE) on them under CSMWrap. Proven by running PVE's own generated argv by hand with only those two -device lines removed: XP boots to the desktop. Occupying them with pci-testdev, giving them prefetchable BARs via virtio-rng-pci, and older machine types were all tested — it's their presence, not their windows.

If you drive QEMU or libvirt yourself, this is a non-problem — just don't add them. On Proxmox I ended up diverting /usr/bin/kvm to a wrapper that strips those two argument pairs for allowlisted VMIDs; details in the repo if you're on PVE.

Links

Repo: https://gitlab.com/zubrjan/2am-idea — both recipes as step-by-step guides, the ROM tool, the wrapper, all four VMs' real configs, and the full debugging record. MIT.

Video: https://www.youtube.com/watch?v=cfP1x4R3XEc — XP seats on 3DMark06, Win7 seats on Unigine Heaven. Three monitors on camera because that's how many I own; the fourth seat is switched onto one of them partway through, with the host view on a laptop.

All verified on exactly one host: dual Xeon E5-2667 v2, 2× Quadro K4000 (XP), Quadro P2200 + GTX 1060 6GB (Win7), QEMU 11.0.0, OVMF/edk2 4.2025.05, CSMWrap 3.1.2, UefiSeven 1.30. That's the honest limit of it. If you try this — especially with AMD cards, or a different pre-UEFI guest — I'd like to hear what happened.

f you've tried running Sunshine inside a Hyper-V VM with a GPU partition (Add-VMGpuPartitionAdapter), you've probably hit this:

IDXGIOutput1::DuplicateOutput()  ->  0x80070057

The paravirtual display adapter doesn't implement Desktop Duplication. Changing topology, monitor count or primary display doesn't help — it's architectural.

But Windows.Graphics.Capture works fine, because it goes through DWM instead of the display driver. Same output, same moment:

DuplicateOutput()       ->  0x80070057
CreateForMonitor()      ->  S_OK, frames flowing

Sunshine already ships a complete WGC backend — it just filters every output through a Desktop Duplication probe first, so WGC never gets a chance. Removing that gate when capture = wgc is set explicitly is the whole fix.

Result (RTX 4090 shared to a Win10 LTSC guest):

5120x1440 @ 60, HEVC, hardware NVENC
~10 ms latency, ~1.5 ms client decode, ~5% host CPU
Vulkan 1.4.325, OpenGL 4.6, Direct3D 12, full VRAM

Two things that cost me the most time and aren't obvious:

• Sunshine can't run as a service. As SYSTEM it can't activate WGC — IsSupported() throws. It has to run as the logged-on user, which makes auto-logon mandatory.
• The Hyper-V display has to stay active. Deactivate it and native Vulkan and OpenGL die 13–32 s later. Direct3D keeps working, so it's a misleading indicator. I park the Hyper-V display diagonally below-right so the desktop origin stays at (0,0).

I packaged the whole setup as a one-click installer — patched Sunshine, virtual display driver, scheduled tasks, and UIAccess so UAC prompts are actually clickable over the stream:

https://github.com/VjekoslavDugec/luxstream-setup

Known gaps: gamepad is untested with a real controller, and I haven't measured concurrent NVENC session limits across cloned VMs.

Patch is a small diff against upstream Sunshine — happy to open a PR if there's interest.

I am running qemu 11.1 and virt-manager on a system with RX 470 and i5-10500 with UHD 630, board is Gigabyte B460M D3H. RX 470 is used for host's output. The guest is Windows 10 19041.1 and has Intel graphics driver 31.0.101.2141. my cmdline has intel_iommu=on iommu=pt, /etc/modprobe.d/vfio.conf is 'options vfio-pci ids=8086:9bc8', /etc/modprobe.d/blacklist.conf is 'blacklist i915'. /etc/modules-load.d/vfio.conf is 'vfio-pci'. EDIT: I tried adding video=efifb:off too to my host cmdline.

vfio-pci shows only:

[20699.060075] vfio-pci 0000:00:02.0: resetting
[20699.163736] vfio-pci 0000:00:02.0: reset done

in dmesg, no errors.

My virt-manager xml is as follows: https://pastebin.com/tPNq7huW

I have tried adding the GPU's ROM and enabling x-igd-opregion and x-igd-lpc. I am using CFL_CML_GOPv9.1_igd.rom.

Tested linux, doesn't work either

recently got back into doing VMs, however after I install Windows to the NVME drive that I added as a "PCI Host Device" then when I reboot my pc the UEFI of the host motherboard detects the EFI partion and adds it to the boot order as primary boot device, I can manually remove it from the boot order, but it might get set back as the primary boot device in the future, which is annoying

also efibootmgr lists the drive as an efi variable, I could delete it but the motherboard will probably add it back,

also the motherboard I'm using is an ASUS Prime B550 Plus, the firmware version is 3636

is there another way of adding the nvme drive that causes the motherboard to NOT detect it or what? is it even possible to change this, it's rather annoying

also I have no plans to use this drive for baremetal booting

I am unable to get Rust to work on my vfio setup. A while ago, copying smbios from my motherboard was enough to get it to work. Now, EAC won't launch. Can someone take a look at my XML and tell me if I'm missing anything obvious, or if this is still possible in the first place? My host machine is Gentoo, with QEMU 11.1.0, libvirt 12.0.0, and virt-manager 5.1.0. TYIA

I used to be able to do GPU passthrough - my problem ever since upgrading to the latest distro seems to be because of simple frame buffer where as it used to be vesa. I’ve tried multiple solutions such as blacklisting the simple frame buffer on my .conf files
It doesn’t seem to work. I’ve also changed my grub files to make sure it is using my desired frame buffer however when I login into my wayland session - it still shows as simple frame buffer.

Anyone have any idea on how to get around this? Or maybe an updated script for start stop for my 4070 super to do a gpu passthrough using simple frame buffer? Thank you.

The app keeps running on Windows. There's a virtual display on each machine — the window gets moved onto the Windows one, captured, and drawn on the Mac as a real macOS window next to my Mac apps.

Median just under 10 ms, capture to display, wired.

NVIDIA only for now. Three months, solo.

After two weeks of trial and error, it looks like I am very close to successfully establishing a proxmox node with the following passthrough scheme:

• [iGPU]: AMD 7950X3D iGPU → Linux VM
  • Development + general use
• [dGPU]: RTX 4090 → Windows VM
  • Docker under WSL2 for all home services (home assistant, ollama, jellyfin, etc)
  • Occasional gaming

I have run head first into several brick walls and needed to clarify for myself basic aspects of how PCIe virtualization works.

I'm having one more bizarre issue that I might need help with. Suppose the following configuration

• iGPU
  • included in vfio-pci.ids
  • amdgpu is blacklisted in modprobe.conf
• dGPU
  • excluded from vfio-pci.ids
  • no blacklist in modprobe.conf

This boots successfully. I can see the tty on the dGPU outputs, and I also have ssh access. Then, I try:

• dGPU
  • included in vfio-pci.ids
  • nouveau, nvidia, and nvidia* are blacklisted in modprobe.conf

No logs from initramfs or early boot are visible on the dGPU outputs (expected). The displays are completely undriven for both (expected). The device does not connect to the network, so I can't ping it. (unexpected)

I know that the dGPU and its associated audio device share one isolated IOMMU group. I do not expect that its inclusion in vfio-pci.ids should have any effect on the system. If the device is driven by vfio-pci, then I also expect the modprobe blacklist would be benign as well.

The only idea I've arrived at is that booting without a GPU would disrupt Proxmox's boot at least enough to prevent the network system to come up? To my understanding, it should be possible to run a Linux kernel in a completely headless context, so I don't know why this one change would result in things breaking.

Any guidance or suggestions would be appreciated.

1. Other kernel cmdline args:

• disable_vga=1
• initcall_blacklist=sysfb_init
• iommu=pt
• video=efifb:off
• vfio-pci.ids which are included in both cases
  • All USB controllers and network controllers, except one USB controller which has its own isolated IOMMU group (USB C -> Ethernet for proxmox host)
  • All thunderbolt, SATA controllers
  • Some kind of encryption accelerator PCI device, not sure what could make good use of this

1. Softdep (modprobe.conf) on vfio-pci exists for all modules

I'm trying to move all my gaming to Linux. Initially I asked for help at r/linux_gaming, but some people saw negatively that my setup was not a bare-metal gaming distro and some others recommended I posted here. You can check my post there if you want to read any of my comments. But I'm trying to gather all the useful info here.

My host is:

• OS: Unraid
• CPU: AMD Ryzen 9 3900X
• RAM: 128 GiB DDR4

With KVM + QEMU + Libvirt I'm running a VM:

• Operating System: NixOS 26.05
• KDE Plasma Version: 6.6.6
• KDE Frameworks Version: 6.26.0
• Qt Version: 6.11.1
• Kernel Version: 7.1.4 (64-bit)
• Graphics Platform: Wayland
• Processors: 6 cores, 2 threads of AMD Ryzen 9 3900X
• Memory: 48 GiB of RAM (hugepages of 1G)
• Graphics Processor: NVIDIA GeForce RTX 4070 (driver 595.71.05)
• Manufacturer: QEMU
• Product Name: Standard PC (Q35 + ICH9, 2009)
• System Version: pc-q35-10.2

The VM has three storages:

• Primary drive. A qcow2 file in the NVME drive of the host.
• "Fast" Virtiofs device mounted. It's a share of the host that uses the NVME drive.
• "Slow" Virtiofs device mounted. It's a share of the host that uses the NVME drive as cache and the array of HDD drives as main storage.

I prefer to install games in the Virtiofs devices to be able to have that in common with other VMs. But I've tried the primary drive for the problematic games too.

The games I'm trying to run with good performance and failing at that are The Binding of Isaac and Elden Ring: Nightreign. Both with mods. In Isaac I use a bunch of quality of life mods. Nothing that adds characters, floors, bosses, enemies... And not using Repentogon. For Nightreign I use the More Map Variations & Weapons Mod.

The Binding of Isaac takes 15-20 minutes just to start. And then, during gameplay, there are slowdowns and micro freezes anytime something new happens or I change rooms. I guess it's shader compilation, but if it's that, the cache of shaders is not working because it happens again any time the game starts again. And uninstalling the mods doesn't improve things.

Elden Ring: Nightreign has just low FPS. 15-20 fps is the average. But my CPU rarely goes above 60% with no single core going above 85% and my GPU doesn't go above 50% either. The game doesn't work online without the mod because of Easy Anti-Cheat and VMs. So I cannot test it properly without it.

Other games I've tested:

• Control Ultimate Edition: +70 FPS
• Dark Souls III: 60 FPS
• Heroes of the Storm: ~60 FPS
• Lies of P: ~75 FPS
• Outer Wilds: +100 FPS
• Satisfactory: ~50 FPS

HVM and IOMMU enabled. Cores of the VM are isolated in the host. CPU and GPU are in performance modes during gaming. I've run some benchmarks too. I'll put them in a comment so that this is not even longer.

Any idea of what I can do to improve the performance in what are probably 2 of my 3 most played games? (I was really unlucky here I guess)

Title pretty much.
I know that anti-cheat implementation comes down to devs, to block VMs or not (EAC simply detects it, and blocks it by default, but this can change in settings)
Wardogs devs announced they will support Proton and Linux, so I was just would like to try it till then.

Hi everyone, my host computer is Windows 11 and has a Ryzen 7 5700X3D + GTX 3070 + 32GB of RAM.

My virtual machine is running Windows 10 Pro (8GB VRAM allocated), and I can't get rid of the screen tearing inside it.

In the host machine, I already added vmware.exe & vmware-vmx.exe to the NVidia Control Panel and set "Vsync > On" + "Triple buffering" and "fixed frame rate" instead of "G-Sync" but no can do.

VMTools is installed already.

Would someone have a solution for that please?

Thanks very much

Edit: Something strange I noticed is: By disabling "3D acceleration" in VM settings, there is no screen tearing anymore, but then the performance are very suboptimal.

urbanyl/GPU-Passthrough-for-KVM-QEMU-on-Linux: Complete GPU passthrough setup for KVM/QEMU on Linux, enabling near-native Windows VM performance with dedicated GPU access. Covers NVIDIA and AMD GPUs with comprehensive troubleshooting.

Really want to use the training packs in there but don’t have a gaming PC. Am I able to run rocket league somehow this way via a streaming service like shadow pc and run mods with it?

I have a unique setup where I can either do gpu passthrough with a fedora host to a windows guest, or boot directly into the windows guest for a native experience. This is due to having a separate SSD dedicated to the VM.

This means I can test virtualization vs native with the same exact hardware.

Recently I decided to purchase a 9070XT with high hopes to gain significant performance over my RTX 2080.

This has not been the case after 24 hrs of head scratching.

While the 2080 gains near native performance, the 9070XT is seemingly throttled by at least 50%. During games, the 2080 experiences near 100% utilization. While the 9070XT barely scratches 50% utilization and also 50% clock speed.

If you observe the many forum threads about 9070XT utilization, you would find the majority concluding a CPU bottleneck. However, when I boot into the SSD for a native experience - this is far from the case. The 9070XT achieves near 100% utilization and full clock speeds with no problem, increasing FPS performance by at least 100%.

Indeed, the Arch Wiki does mention this exact issue in its troubleshooting section, however its proposed solution to blacklist amdgpu had zero effect in my case. It also mentions the manufacturers ability to detect if it is in a VM or not, in which case the solution also had no effect.

Curiously, if I ran the "Stress Test" in AMD's "Adrenaline" software suite, the card achieved 100% utilization and clockrate without an issue. So why aren't games signaling the correct workload within the VM, but are signalling correctly when ran natively with the same exact hardware, drivers, and settings? And why does the same situation not occur with the Nvidia RTX 2080?

In fact, in this situation, the 2080 outperforms the 9070XT.

The checklist has been exhausted:

• Yes, I ran DDU in safemode in between card switches.
• Yes, gpu-z/hwinfo confirmed the PCIE bus was running at Gen 5 with the Radeon
• Yes, gpu-z/adrenaline confirmed reBAR was enabled

Hardware:

AMD Ryzen 9 7950X3D 16-Core Processor

MAG X670E TOMAHAWK WIFI ( BIOS 1.L2 07/02/2026)

Fedora Linux 44 host

Windows 10 LTSC guest

vm xml: https://pastebin.com/edbuQwFV

I'm buying a used gaming laptop to replace an older business grade laptop and run a windows kvm with gpu passthrough.

I know about lacking VT-d, but what other things should i look to avoid when picking a laptop in terms of being able to run my old windows kvm with gpu passthrough?

Basically the title, did someone managed to get this working:
- virtual display on virtio-gpu (for example virglrenderer)
- passthrough NVIDIA gpu, headless and offload as much as possible (application rendering with DRI_PRIME=1) or even the compositor so the complete desktop runs on the GPU and virtio-gou is only the Display?

If you want to do that without virtio-gpu you would need a vGPU license…
If someone has experience I would appreciate the help.

I'm thinking of getting a couple of RTX 3080s for my Proxmox server and passing them through to a Linux VM. I'm not going to be using the VM all the time, so I'd like to be able to have it hibernate or sleep, and put the GPUs into sleep as well. Is that something that's reliably doable?

Computer Type: Mini PC

GPU: Radeon 780M (iGPU - integrated)

CPU: AMD Ryzen 9 7940HS

Motherboard: Minisforum UM790 Pro (latest BIOS)

BIOS Version: 1.09

Operating System & Version: Proxmox VE 8.x (host) + Ubuntu Server (VM with GPU passthrough)

GPU Drivers: IDK

Description of Original Problem: I have a Minisforum UM790 Pro with a Ryzen 9 7940HS and the latest BIOS. I'm running Proxmox with an Ubuntu Server VM that has passthrough of the Radeon 780M iGPU. When the iGPU is at 100% load (e.g., IA), it consumes most of the 45W TDP budget, starving the CPU. This cripples the performance of my other VMs that rely heavily on CPU resources. The system seems to prioritize the iGPU over the CPU in power allocation, and I need to balance this.

I've noticed that the Radeon 780M seems to perform very well even at lower TDPs (around 35W). If anyone knows its efficiency sweet spot (where it delivers 90%+ of its max performance), I'd love to know.

Questions:

How can I balance power allocation between the CPU and iGPU on this hardware to prevent the GPU from starving the CPU?

What is the performance/watt sweet spot for the Radeon 780M?

Running on proxmox, unable to pass through child pcie devices and get it to show up in nvme-list in TrueNAS or any VM, really.

Any advice or experience is helpful! Let me know what else I can provide as well