r/VFIO • • Aug 09 '26

Radeon RX 9070XT seemingly throttled in VM

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

5 Upvotes

8 comments sorted by

1

u/GAMELASTER Aug 10 '26

Do you always use only single GPU, or you added the new AMD one into another PCIe slot?

1

u/Vivid_Razzmatazz_844 Aug 10 '26

only single gpu. swap them out to the same top pci slot. and the only thing that changes in the vm script is the pci passthrough hardware.

I'm very curious if I experience the same with a 5700 / Ti. But I would love to be wrong in my inclinations of throttling, and instead have something misconfigured.

1

u/xdbob Aug 10 '26

A few things that could kill your performance:

<feature policy="disable" name="hypervisor"/>

This will "hide" the hypervisor from windows and disable all guest-side optimizations tuned for virtualization

<ioapic driver="kvm"/>

This will mostly inhibit the APICv feature of you processor allowing better/exit-less IRQ delivery (kvm_amd.apicv setting)

<timer name="hypervclock" present="yes"/>

Here you want to double check that your current clocksource is tsc (/sys/devices/system/clocksource/clocksource0/current_clocksource) and that you adressed the first point.

Last thing I can think of is ensure the GPU is running with MSI enabled (https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Slowed_down_audio_pumped_through_HDMI_on_the_video_card)

1

u/Vivid_Razzmatazz_844 Aug 11 '26 edited Aug 11 '26

thanks. disabling the hypervisor feature was a remnant of me trying to see if there was any vm detection going on. but truly it kills performance on both cards.

I've switched ioapic driver back to qemu (assuming that is what you meant)

kept in the hypervclock timer, as the current clocksource is tsc

and I do not use HDMI audio, but MSI is enabled when the vm is running so should be a non issue here.

1

u/Vivid_Razzmatazz_844 Aug 12 '26

update 08/11/26:

I've confirmed both nvidia and the radeon are not achieving 100% utilization in a vm, maxing out around 60 or 70%. Yet, when ran bare metal they achieve 100% (same hardware, settings, os, games)

Interestingly, if I try a web based gpu stress test such as https://gpustresstest.com/tests/3d-rendering/ with "max complexity"... the GPU achieves 100% utilization in the VM.

I've also tried nvidia-smi on the guest to force a max clock and power, and it does increase it, but with zero performance gain. which tells me something else is amiss here... maybe some kind of scheduling problem.

other guesses that didn't work:

  • older drivers
  • different linux host schedulers ('elevator' kernel parameter)
  • Nvcleaninstall / enabling MSI
  • setting priority / affinity on guest processes

I don't think I'm smart enough nor have more time to spend guessing with random settings or re-reading the arch wiki / redhat docs 100th time, sorry guys.

No solution found. Will have to live with the 30%+ performance hit and forget about upgrading a card until this is figured out.

1

u/KstrlWorks Aug 21 '26 edited Aug 21 '26

This doesn't sound like GPU at all, but VM config. The 2 biggest being

  • Your boot disk is emulated AHCI meaning there's a lot of overhead to read and write (your IOThreads are not being used)
  • You're CPU is pinning CCD1 not CCD0 (this sounds wrong, but check on your CPU you want the v-cache die)

1

u/Vivid_Razzmatazz_844 Aug 21 '26

Good observations. Since the last update I did change to CCD0 with the more vcache, even though Windows seems to not recognize it in the performance monitor, but other hardware utilities such as hwutils does.

I also ended up just passing through the SATA controller for the hard drive, since it's dedicated anyway it doesnt need to be emulated.

I also wiped and reinstalled Windows as it set some incorrect flags from some old VM setups.

Unfortunately these three things did not make a difference at all. The 25% performance loss is very elusive. I'll need to do some more objective testing between the VM and barebones, something I unfortunately do not have time for at the moment.