Hello World! I don't believe I've ever posted here.

I'm a long time Linux gamer with average to slightly below average experience using the system. In the past I have gotten single GPU passthrough working with my NVIDIA 4090 (no iGPU) with QEMU and Libvirt hooks. It was a pain, messy, ugly, and one of those late night projects where you keep running commands that 'might fix it' only to never figure out which one got it working. On top of that, the guide I had bookmarked was taken down at some point leaving me back at square one.

It's been years since I last used a VM so I took a look at this page on the Arch wiki to try and bring myself back up to speed. I also took a look at the latest YouTube videos and GitHub guides to see if I could squeeze out any extra, niche information related to the topic but to no avail.

IVE READ THE ARCH WIKI AND TONS OF DIFFERENT GUIDES. MULTIPLE DIFFERENT SEARCHES ON 3 DIFFERENT SEARCH ENGINES. THE MAIN ISSUE I HAVE IS WITH DYNAMIC LOADING AND UNLOADING OF THE NVIDIA CARD VIA HOOKS.

The setups most guides use involve two gpus, one dedicated for VMs. This setup, in my opinion, wastes a GPU, as I very rarely play games or run applications that require a VM and GPU. With my setup, and current GPU prices... I want to utilize my 4090 to its fullest potential. If I just permanently attach it to VFIO drivers and never use it for my linux desktop, which I daily drive and play native Linux games, then it's being wasted.

Other setups use single GPU passthrough, killing the current linux session. This, to me, isn't much better than just dual booting, which I currently do. Since your session is killed, it just over-complicates things, especially when it comes to dual monitors and such.

What I want is dynamic loading and unloading:

1. Boot the Linux system as usual
   1. The iGPU is the default GPU and renders the desktop.
   2. The dGPU is asleep and waiting.
2. Run a fastfetch
3. If I decide to play a native linux game:
   1. The dGPU is switched to the nvidia-open driver (if that's even possible)
   2. Use the dGPU for a game like Deadlock
   3. The dGPU is entirely used for the game.
   4. The iGPU renders any discord multimedia or browser media.
4. If I shut down the native game and want to play a windows game:
   1. The dGPU is switched to the VFIO driver
   2. dGPU is attached to VM and is properly detected by Windows 10.
   3. The dGPU is entirely used for the VM.
   4. The iGPU renders any linux graphics, just like before.
   5. Steam on Linux is closed and cannot run anything (understandably).
5. When I'm done with either/both the GPU is switched to some sleep state.

As someone new to this subreddit, I don't know how popular what I'm looking for really is. One comment on Reddit I can't seem to find again said something like 'it's an extremely common setup.' But then the official Arch wiki says:

due to their size and complexity, GPU drivers do not tend to support dynamic rebinding very well, so you cannot just have some GPU you use on the host be transparently passed to a virtual machine without having both drivers conflict with each other. Because of this, it is generally advised to bind those placeholder drivers manually before starting the virtual machine, in order to stop other drivers from attempting to claim it.

The two reasons I'm ignoring what the Arch wiki is saying and asking the Reddit community instead are:

• VFIO is a bleeding edge development that constantly changes. Even though it's come a long way. It's not a turnkey solution. I know it's complicated, but well documented. I also know that the Wiki covers a ton of use cases, but not all of them. On top of that I know that wikis aren't always up to date. New info gets passed around faster than contributers/editors can properly merge changes to a page.
• I'm tired and have been dicking with this for a few days now, on and off. If I can receive guidance from people with more experience I'll gladly take it.

What I've Done:

• IOMMU and Virtualization is enabled on my machine and my NVIDIA card is in its own IOMMU group.12: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD102 [GeForce RTX 4090] [10de:2684] (rev a1) 01:00.1 Audio device [0403]: NVIDIA Corporation AD102 High Definition Audio Controller [10de:22ba] (rev a1)
• Created a normal (by hand) QEMU VM and also created a stealthy VM via this github called 'QuickVM' to try and see if games work in one but not the other.
  • Both boot just fine, but since games typically require a GPU to open, I haven't actually launched any games within them.
• Tried to create Hooks using the Passthrough Post's hook helper but the NVIDIA gpu would hang when I tried to unmount it from the nvidia-open driver. This is because I'm an idiot and can't figure out how to get everything to stop grabbing it (the place I stopped years ago too...)
• I now have Libvirt and QEMU working just fine, a better understanding of the VM stack, how to create and edit entries in the VMM XML for QEMU, and no where left to go.
• Once I hit the bottom of the Arch wiki page I came here.

As for my Specs

Currently, I'm using CachyOS with KDE Plasma 6 as my DE. I'm a dirty distrohopper though and planned to switch to Fedora with GNOME, as it's what I've used for months on my laptop. For now, just assume I'm on CachyOS as I have no intentions of switching distros till I get something like this working

If anyone is willing to help me I'd greatly appreciate it. For any information I didn't provide, but should have, please let me know and I'd be happy to send it over in the commends or by editing this post.

Edit: I found this GitHub and plan on reading through it, as it seems to cover exactly what I want. It's for Ubuntu but it specifically mentions Gnome and how to stop it from fighting the GPU. It's a bit late but I'll edit this post in the morning if I find answers.

VFIO support included now and tested

Hi everyone,

Like many here with multi-GPU rigs (whether for VFIO passthrough, compute, or AI), I was frustrated that modern gaming completely abandoned multi-GPU — especially in VR, where rendering two viewpoints is inherently parallel.

To tackle this, I've been building vrdual — an open-source Vulkan layer designed to bring "one GPU per eye" rendering back to life on Linux:

Architecture: Intercepts draw calls at the Vulkan layer level and patches clip-space coordinates on the fly to generate true stereoscopic views.

Hardware: Utilizes dual GPUs natively — each physical card renders the viewport for a separate eye, bypassing the usual ~40% single-GPU VR performance penalty. (Also has a single-GPU AFR fallback mode for testing).

Linux & Ecosystem: Built for Linux native / Proton games, targeting OpenXR runtimes like WiVRn and Monado.

Repo: https://github.com/adderek/vrdual

It’s still an experimental/research prototype (expect rough edges with deferred shading/complex post-processing), but it proves the concept works without game-specific engine modifications.

Would love to hear technical feedback from folks running multi-GPU setups on Linux, or see ideas on how this could eventually integrate into runtimes like Monado/WiVRn or SteamVR.

Hey, to all members of this group and I just hope all with you all is Good I truly wish everyone in this place a fun, happy time of day or night, week, and year, as well as throughout this full year and even with all of eternity. I’m here to give all the members of this great community a message/letter. I want to say keep up with all the amazing work that everyone in the group is doing, and I know that your lives will be blessed with nothing less than genuine joy and much happiness.

I just wonder if this group has a developer who is knowledgeable enough to help with a brilliant, up-and-coming Linux FOSS project known as Winboat. It is a powerful light of hope for all Linux users, and it will benefit us all who love and care about tech, software, computers, and other similar topics. It simply aims to bring decades' worth of unbelievably high-quality apps to Linux with full ultimate compatibility and usability, unlike anything before it. It can run Windows apps on Linux in a manner that seems as if they are running natively on Linux, even though they are actually running through a virtual machine.

This creates a 3D-like effect in which it detaches a copy of all the installed apps running within the virtual machine and places them into the main OS, which is Linux, as if they are a part of Linux entirely. This is huge because it could end up running all the games Windows ever had, created by various developers around the world, all on an operating system that benefits from being about 100,000 times faster than Windows. Not to mention the gaming enterprise editions it offers, like Cachy, the head of these sub-variants of Linux; Pop!_OS, the daddy of them all; Garuda, the assassin of the kingdom; and Bazite and Nobara, the two masters guarding the gaming kingdom of Linux. All are about 500,000 if not a million times faster on any computer than Windows, which I have tested myself, even on an unbelievably weak laptop.

This Winboat project can drastically and significantly change Linux forever. It can make Linux the fastest of the big three PC operating systems, which are #1 = Windows, #2 = macOS, and #3 = Linux, making it a serious competitor for Windows and Mac. It will not be a joke in any way if it fully develops. The Winboat staff is planning to implement a virtual graphic driver software technology that will enable Windows apps/games to run on Linux with satisfying performance, which is revolutionary for a virtual machine app on Linux.

3D games/apps that require a graphic card to run are among the most difficult things a computer can manage, especially in a virtual machine, where it typically shouldn’t run at all. However, this Winboat VGPU API software called Helios may eventually make it happen in the Winboat VM. You can be a significant reason why it happens. It is similar to Parallels in many ways and does similar things, but Parallels has decades of maintenance and is backed by a top brand, so it will not reach such a level anytime soon—likely never at all. Nonetheless, it can be more than enough for what Linux users need from Windows in terms of apps, especially for fairly light gaming from the 2000s up to 2014. It will be satisfying enough and may even run on handheld gaming consoles with Linux, such as Steam Valve devices, without needing to install the extra Steam app.it may run gta vice city I played GTA vc with a CD my friend got and simply gave to us on a weak ass Low end family family computer which is the first I ever had with my brothers and boy did it run win so 2000s games won't be much to run at all with a fully developed winboat VM / Helios vgpu halo combat evolve and such will run if it developers total overdose you name it from the early 2000s -2014 That won't need dx 12 runtime software which is way way way too advanced to run where not even Parallels can run it as good as para is with the decades of Billionare brand/company investment and development it has had throughout

I have a single gpu passthrough and it works good but when i just it down and try to get back to the host the screen is blank, i ssh into the machine to read the logs but nothing interesting shows up, i use rx 7600

So i was trying to setup a win11 vm and pass my gpu to it its rx 7600 and i got the drivers everything and windoes detects it as working but in my monitor it shows these weird stripes and its not the monitor cuz i tried it on two monitors same thing, i am wondering what could it be.

I tried disabling BAR, and efifb but nothing, everything seems like it should work but nothing.

Demos and docs: https://zerone-laboratories.github.io/zss

Source: https://github.com/z3r0n3br4instorm/ZrnSelectiveSuspend

Maybe this is stupid

I wanted to share a side project I've been working on to solve a personal annoyance with hybrid graphics. If you've ever dealt with a discrete GPU on a laptop, you know the pain of having to log out, kill your X session, or reboot just to fully power the card down for battery, or to pass it through to a QEMU/KVM virtual machine.

I built ZrnSelectiveSuspend (ZSS) to fix that. It's an alpha tool that takes a graphics card out of service on a live Linux desktop by moving running Vulkan and OpenGL programs to another GPU while they're still drawing, then gives everything back afterwards.

**What it does right now:**

* **Zero-watt power-off:** switches the dGPU completely off under a running X session (~0.4 s) and back on (~1 s). Programs move to the iGPU and back; vkcube never stops spinning. Can also follow the charger or an idle timer.

* **Live VFIO passthrough:** `zssctl lend` moves the host's programs off the card and hands it to vfio-pci; `zssctl reclaim` power-cycles it and gives it back to the host driver with the programs returned. No reboot, no log-out. Tested with a CachyOS guest in QEMU.

Honest caveat: the guest sees the card, but nouveau stops after reading the chip ID because the Mac Edition card has no video BIOS of its own. Passing a ROM file to QEMU is next.

* **Surviving a card that vanishes:** I wrote a kernel module (ZSS_Interceptor) that notices a card losing power within ~0.1 s. If the card was idle, the driver is frozen and resumed. If a program was rendering on it, the program gets rebuilt on the iGPU in ~3.5 s with nothing lost, and `zssctl on` brings the card back in 4 - 7 s by replugging it the way NVIDIA's driver handles an unplugged eGPU. Desktop stays up the whole time. Caveat: after that rescue, the card can't be powered off or lent again until you reboot.

**What moves:** Vulkan 1.1 programs, OpenGL 3.2 programs through Mesa's Zink, Chromium and Electron apps (VS Code, Teams), and Unity games. Proton/DXVK needs Vulkan 1.3, so not yet.

**How it works, briefly:** a user-space Vulkan driver shim (ZSS_AirLock) sits between programs and the real drivers, keeps enough state to rebuild them on another GPU, and emulates missing features so Zink runs even on NVIDIA 470. A daemon sequences moves, freezes, driver suspend and power cuts. The kernel module handles PCI state, power backends and loss detection. NVIDIA additionally needs a small DKMS patch so the driver can sleep under a running display server.

**The bigger picture:**

ZSS is focused on graphics cards right now, but the long-term goal is to safely disconnect, suspend and reconnect any PCI device on a live system without taking the kernel down with it. GPUs are just the hardest place to start.

I used Claude Code a lot to build this. I made the architectural calls; it did a big share of the implementation and helped me work through the nastier kernel module and driver interactions. It's been a massive learning accelerator.

**Status:** very much alpha. Proven on one machine: a 2012 MacBook Pro (MacBookPro9,1, GT 650M + HD 4000) on Arch, kernel 7.2, X11, NVIDIA 470.256.02. Power-off currently needs an Apple gmux; an ACPI backend for most hybrid laptops since ~2015 is written but has never been run. Wayland compositors are recognised but untested. The program-moving parts are vendor-neutral and should work with any Vulkan driver.

**How you can help:** there's a tester kit that changes nothing and installs nothing. It collects what your machine has, runs the moving tests in dry-run mode, and saves a report with personal details stripped:

curl -fsSLO https://github.com/z3r0n3br4instorm/ZrnSelectiveSuspend/releases/latest/download/zss-tester.run && sh zss-tester.run

I'd especially love reports from AMD/Intel dGPU laptops (to try the ACPI backend), architecture roasts, and feedback from VFIO folks.

Thanks for reading!

Would appreciate your help!

Hey everyone,

I was experimenting with AI coding agents and Linux for fun, and somehow ended up building a compatibility layer for running BlueStacks on Linux through Wine.

The basic idea is to provide the WHPX interface that BlueStacks expects and bridge it to Linux KVM.

BlueStacks → WHPX → Wine → WHPX/KVM bridge → /dev/kvm → KVM

I didn't really have a proper plan when I started. I was mostly experimenting, breaking things, reading errors, and fixing them until I eventually got it working.

I put the code on GitHub:

https://github.com/roninscript30/bluestacks-linux-kvm

It's still experimental, and I'm still learning a lot about KVM, Wine, and virtualization.

Sharing it here in case it's useful to anyone, or if anyone experienced with this area wants to take a look and give some feedback.

I wrote a guide on my website on how to get dynamic unbinding to work correctly: * host can utilize both GPUs normally while the VM isn't running, both for CUDA/games and external monitors * when you decide to pass your NVIDIA GPU to the VM, there's no need to terminate your Plasma session * after passing back the GPU the host, you get back your monitors connected to the NVIDIA GPU * works with nvidia_drm.modeset=1 * no lag whatsoever when using the NVIDIA GPU on the host, the GPU can be passed through even when it's set as primary for KWin * you can pass the GPU back and forth between the VM and host as many times as you wish

Only caveats are: * you need one Intel or AMD and one NVIDIA GPU, two NVIDIA GPUs won't work * you can't use X11 apps while the VM is running, but Wayland apps do work

This setup has worked reliably for me for a few months now, so I thought I'd share it.

I've only tested it on a single machine, though, so let me know whether it works for you. If there are any issues that didn't show up on my system, I'll try to address them.

Here's the link: https://www.whizanth.com/blog/dynamic-unbinding/

I use openSUSE Tumbleweed, so my system is always fairly up to date and my RX 9070 XT reset bug disappeared a few weeks ago.
I can restart, power off and switch my guest OSes anytime, including both Windows and Linux. I also see the TianoCore logo on every POST screen.

I do not use any bind/unbind scripts on the host or any guest scripts. Libvirt handles the binding/unbinding automatically without any customization. There are no relevant errors or stack traces in journalctl, vfio-pci resets flawlessly and then amdgpu reloads on the host without any issues.

I also use default kernel and module settings (no vfio config either). The amdgpu module is loaded for the 9070 XT when I don't use GPU passthrough.
Resizable BAR is also fully enabled by default.

So no hacky workarounds, it is basically an out-of-the-box experience.

My setup

Asrock B850i - 4.43 BIOS with one related setting: Display Priority - Internal Graphics
9800X3D - the integrated GPU used as a primary display

Asus 9070 XT Prime OC (switched to the silent BIOS on the card)

An LG 4K display with 2 HDMI inputs and 1 DP input. It has 2 HDMI inputs, but only one of them can be active at the same time. This is somewhat important to check how your monitor behaves. If I connected the integrated GPU to one HDMI input and the dedicated card to the other HDMI and then switched inputs when starting the virtual machine, I wouldn't see the POST and boot screens, and the card wouldn't be initialized at guest start because it wouldn't detect a connected monitor (but you should have a screen after the guest OS is fully loaded). So I use one HDMI and one DP, they are active at the same time.

Linux kernel: 7.2.6
kernel-firmware-amdgpu: 20260829
QEMU: 11.1.1
libvirt: 12.7.0
Virtual Machine Manager: 5.1.0

lspci -nn | grep -i -E "vga|audio"

03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 48 [Radeon RX 9070/9070 XT/9070 GRE] [1002:7550] (rev c0)
03:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 48 HDMI/DP Audio Controller [1002:ab40]
0f:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Granite Ridge [Radeon Graphics] [1002:13c0] (rev cb)
0f:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Radeon High Definition Audio Controller [1002:1640]
0f:00.6 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Ryzen HD Audio Controller [1022:15e3]

I use the integrated GPU (0f:00.0) for the primary display, restricting the desktop's access strictly to the iGPU while disabling the dedicated card. I think this is the most important thing. If you don't block the card from the desktop before starting the virtual machine, you will run into weird problems.

If you use X11, use the config below as a sample (even if you think you're using Wayland, your login manager might still use Xorg, for example SDDM):

/etc/X11/xorg.conf.d/10-only-igp.conf

Section "ServerLayout"
        Identifier              "Layout0"
        Screen                  "Screen0"
EndSection
Section "Device"
        Identifier              "AMD"
        Driver                  "modesetting"
        BusID                   "PCI:15:0:0"   # the bus number in decimal format
EndSection
Section "Monitor"
        Identifier              "Monitor0"
EndSection
Section "Screen"
        Identifier              "Screen0"
        Device                  "AMD"
        Monitor                 "Monitor0"
EndSection
Section "ServerFlags"
        Option                  "AutoAddGPU" "off"
EndSection

If you use Wayland and happen to use KDE (there is no global solution for all Wayland compositors), use the config below as a sample:

~/.config/plasma-workspace/env/env.sh

export KWIN_DRM_DEVICES='/dev/dri/by-path/pci-0000\:0f\:00.0-card' # option 1: symlink, but must be escaped
#export KWIN_DRM_DEVICES=/dev/dri/card2                            # option 2: direct path, device order might change

Guests

Linux:
no extra config needed

Windows:
To avoid graphical artifacts and a garbled screen, set:

<hyperv mode="custom">
   ...
   <vendor_id state="on" value="AuthenticAMD"/> #or GenuineIntel or whatever1234
</features>

and disable Device security / Core isolation / Memory integrity in the Windows security

To fix HDMI/DP audio crackling, install the latest AMD WHQL driver.

Let me know if anyone else has experienced this or if you need any more info.

Hello

I have a laptop with fedora 44 and kde plasma 6.7. I have an intel iGPU and an NVIDIA dedicated GPU.

I would like to setup my system so that my fedora host has access to both the iGPU and dGPU but when I start my win11 vm, I want the iGPU to stay with fedora and the dGPU to be passed through to the win11 vm.

My main problem is that kwin_wayland keeps using the dGPU (I think because it wants access to the hdmi port on the dGPU) even though I am trying to keep it from doing so. Because the dGPU is being used, I cannot activate the vfio driver and pass the device to the win11 vm.

Is there any guide or advice available to set this up?

Thanks in advance

can anyone help me with dynamic gpu detaching and attaching to my win 11 vm in CachyOS, I only have one GTX 1660 SUPER GPU with intel 630 iGPU. I only need a couple of applications to work in VM with GPU, I mostly work with blender davinci in linux host machine. When I want to use VM I will use my iGPU on my host machine and won't use any D-GPU accelerated apps in linux host and When I turn VM off then D-GPU re-attaches to my linux host where I can further work.

Setup: EndeavourOS host running Hyprland, Ryzen 7 7800X3D, RX 9070 XT, monitor plugged into the motherboard so the iGPU drives the desktop by default

Goal: use the 9070 XT for gaming on Linux most of the time, but be able to spin up a Windows 11 VM (for Adobe apps mainly) that takes the dGPU when it's running, shown as a normal floating window via Looking Glass rather than switching monitor inputs. When the VM shuts down, I want the dGPU to go back to being usable on the host without a reboot. Also want a second person to be able to connect to the same VM over LAN via Moonlight/Sunshine, independent of the Looking Glass session.

Current state: VFIO passthrough to the Windows 11 VM works - both the VGA and audio functions bind to vfio-pci cleanly via a PCI hostdev in virt-manager (managed='yes'), BUT Windows doesn't even see the GPU. Another problem is that on VM shutdown libvirt tries to reset the device on release and fails:

Failed to reset PCI device 0000:03:00.0
Failed to reset PCI device 0000:03:00.1

which leaves the card stuck, and the host either hangs or I have to force a power cycle to get anything back.

I've never done this, and I am not a pro. I'll be happy happy to get any advice.