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.

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.

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

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.

☠️Hey everyone! I’m trying to set up a dual-box arrangement to play Sea of Thieves

with someone else in my house using 2 Virtual Machines (VMs),

but I only have a single RTX 3070 in my PC.

I have two main roadblocks: how Can I split/virtualize my single GPU across two VMs effectively for gaming?

How do I bypass the Easy Anti-Cheat (EAC) "VM Detected" error (specifically triggered by GPU)

What software or hypervisor setup would you recommend for this?

Or is there a completely better, budget-friendly alternative to running two instances of SoT on one PC?

Or can i do this in windows itself without running a VM? I tried running the game through steam and the xbox app at the same time but that gives me a error..

Appreciate any advice! 👇

I got AMD GPU-PV working in a normal Linux Hyper-V VM on my RX 9060 XT.

This isn't WSL — it's a regular Ubuntu 24.04 Generation 2 Hyper-V VM using dxgkrnl + the WSL D3D12 userspace + the matching AMD UMD from the Windows driver.

Repo:

https://github.com/Speedstu/mirage-gpupv

On my machine I get:

• D3D12 (AMD Radeon RX 9060 XT) through Mesa
• working OpenGL ES acceleration
• actual GPU render/readback with the expected pixels
• the Radeon stays attached and usable by Windows

I wrapped the whole setup into a PowerShell script that handles the GPU-P configuration, finds the active AMD driver package, copies the required userspace files into the guest and runs a smoke test at the end.

The important part for me was getting actual GPU work/readback rather than just seeing /dev/dxg exist.

Tested setup:

• Windows 11 + Hyper-V
• RX 9060 XT
• Ubuntu 24.04 Gen 2 VM
• dxgkrnl
• Mesa D3D12

It's still experimental and I've only validated it on my RX 9060 XT so far.

If anyone has another Radeon exposed by Get-VMHostPartitionableGpu, I'd be interested in results. Failures are useful too since I'd like to figure out which generations actually work.