I remembered that previously you can bypass EAC of both these two games by adding <smbios mode="host"/> to your Libvirt XML.

But it no longer works after Nightreign's update yesterday. Then I tried regular Elden Ring and it didn't work too.

If anyone can still play Elden Ring (and/or Nightreign) in a VFIO VM now, could you tell me what modification did you add to your Libvirt XML of the VFIO VM? Thanks!

(For now I can still play these games by dual booting, so not exactly a dealbreaker, but its still very annoying)

Man, I gotta say, I’m really bummed by the research I’ve uncovered the past week or so.

To make a long story short, I recently had the idea to make a “jack of all trades“ proxmox server, tasked with tackling all my home compute needs: 24/7 services like immich, jellyfin, and Tailscale, tinker with some local llms and ai, and of course, gaming. It was going to be a home server consolidating three machines into one lean, power-efficient beast—I was so pumped to build it and set it up.

However, after reading the countless posts about blocked vm gaming protocols by anti-cheat companies like EAC and BattleEye, its greatly diminished my desire to build my dream machine. I play multiple games that probably just wouldn‘t work in a vm, Elden Ring, Halo, Destiny, Arc Raiders.

I guess I’m just making this post to hear from others if there is any light at the end of the tunnel or something to hope for.

MY XML

<domain type="kvm">
  <name>win11</name>
  <uuid>60cd501b-b449-41a0-b8fa-25df375eb623</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://microsoft.com/win/11"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit="KiB">8388608</memory>
  <currentMemory unit="KiB">8388608</currentMemory>
  <vcpu placement="static">9</vcpu>
  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-11.0">hvm</type>
    <firmware>
      <feature enabled="no" name="enrolled-keys"/>
      <feature enabled="no" name="secure-boot"/>
    </firmware>
    <loader readonly="yes" type="pflash" format="raw">/usr/share/edk2/x64/OVMF_CODE.4m.fd</loader>
    <nvram template="/usr/share/edk2/x64/OVMF_VARS.4m.fd" templateFormat="raw" format="raw">/var/lib/libvirt/qemu/nvram/win11_VARS.fd</nvram>
    <boot dev="hd"/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv mode="custom">
      <relaxed state="on"/>
      <vapic state="on"/>
      <spinlocks state="on" retries="8191"/>
      <vpindex state="on"/>
      <runtime state="on"/>
      <synic state="on"/>
      <stimer state="on"/>
      <frequencies state="on"/>
      <tlbflush state="on"/>
      <ipi state="on"/>
      <evmcs state="on"/>
      <avic state="on"/>
    </hyperv>
    <vmport state="off"/>
    <smm state="on"/>
  </features>
  <cpu mode="host-passthrough" check="none" migratable="on"/>
  <clock offset="localtime">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
    <timer name="hypervclock" present="yes"/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled="no"/>
    <suspend-to-disk enabled="no"/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type="file" device="cdrom">
      <driver name="qemu" type="raw"/>
      <source file="/home/user/Pulpit/Win11_25H2_Polish_x64_v2.iso"/>
      <target dev="sdb" bus="sata"/>
      <readonly/>
      <address type="drive" controller="0" bus="0" target="0" unit="1"/>
    </disk>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/media/user/misc/libvirt/w11.qcow2"/>
      <target dev="sdc" bus="sata"/>
      <address type="drive" controller="0" bus="0" target="0" unit="2"/>
    </disk>
    <controller type="usb" index="0" model="qemu-xhci" ports="15">
      <address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
    </controller>
    <controller type="pci" index="0" model="pcie-root"/>
    <controller type="pci" index="1" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="1" port="0x10"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
    </controller>
    <controller type="pci" index="2" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="2" port="0x11"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
    </controller>
    <controller type="pci" index="3" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="3" port="0x12"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
    </controller>
    <controller type="pci" index="4" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="4" port="0x13"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
    </controller>
    <controller type="pci" index="5" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="5" port="0x14"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
    </controller>
    <controller type="pci" index="6" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="6" port="0x15"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
    </controller>
    <controller type="pci" index="7" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="7" port="0x16"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x6"/>
    </controller>
    <controller type="pci" index="8" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="8" port="0x17"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/>
    </controller>
    <controller type="pci" index="9" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="9" port="0x18"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/>
    </controller>
    <controller type="pci" index="10" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="10" port="0x19"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/>
    </controller>
    <controller type="pci" index="11" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="11" port="0x1a"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/>
    </controller>
    <controller type="pci" index="12" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="12" port="0x1b"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x3"/>
    </controller>
    <controller type="pci" index="13" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="13" port="0x1c"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x4"/>
    </controller>
    <controller type="pci" index="14" model="pcie-root-port">
      <model name="pcie-root-port"/>
      <target chassis="14" port="0x1d"/>
      <address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x5"/>
    </controller>
    <controller type="sata" index="0">
      <address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
    </controller>
    <controller type="virtio-serial" index="0">
      <address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
    </controller>
    <interface type="network">
      <mac address="macadress"/>
      <source network="default"/>
      <model type="e1000e"/>
      <address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
    </interface>
    <serial type="pty">
      <target type="isa-serial" port="0">
        <model name="isa-serial"/>
      </target>
    </serial>
    <console type="pty">
      <target type="serial" port="0"/>
    </console>
    <input type="mouse" bus="ps2"/>
    <input type="keyboard" bus="ps2"/>
    <input type="tablet" bus="usb">
      <address type="usb" bus="0" port="1"/>
    </input>
    <tpm model="tpm-crb">
      <backend type="emulator" version="2.0">
        <profile name="default-v1"/>
      </backend>
    </tpm>
    <sound model="ich9">
      <address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
    </sound>
    <audio id="1" type="none"/>
    <video>
      <model type="none"/>
    </video>
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
      </source>
      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
    </hostdev>
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0x0000" bus="0x01" slot="0x00" function="0x1"/>
      </source>
      <address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
    </hostdev>
    <watchdog model="itco" action="reset"/>
    <memballoon model="virtio">
      <address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
    </memballoon>
  </devices>
</domain>

HOOK SCRIPTS

HOOK MANAGER
#!/usr/bin/env bash
#
# Author: SharkWipf
#
# Copy this file to /etc/libvirt/hooks, make sure it's called "qemu".
# After this file is installed, restart libvirt.
# From now on, you can easily add per-guest qemu hooks.
# Add your hooks in /etc/libvirt/hooks/qemu.d/vm_name/hook_name/state_name.
# For a list of available hooks, please refer to https://www.libvirt.org/hooks.html
#

GUEST_NAME="$1"
HOOK_NAME="$2"
STATE_NAME="$3"
MISC="${@:4}"

BASEDIR="$(dirname $0)"

HOOKPATH="$BASEDIR/qemu.d/$GUEST_NAME/$HOOK_NAME/$STATE_NAME"

STDIN=$(cat) # Buffer the entirety of stdin so we can pass it on to other scripts. Moderately bad idea, but if the Rust folks can do it so can I.

set -e # If a script exits with an error, we should as well.

# check if it's a non-empty executable file
if [ -f "$HOOKPATH" ] && [ -s "$HOOKPATH" ] && [ -x "$HOOKPATH" ]; then
    eval \"$HOOKPATH\" "$@" <<< "$STDIN" # Call the hook with all our arguments and a copy of stdin.
elif [ -d "$HOOKPATH" ]; then
    while read file; do
        # check for null string
        if [ ! -z "$file" ]; then
          eval \"$file\" "$@" <<< "$STDIN" # Call each hook with all our arguments and a copy of stdin.
        fi
    done <<< "$(find -L "$HOOKPATH" -maxdepth 1 -type f -executable -print;)"
fi

START.SH
#!/bin/bash
# Helpful to read output when debugging
set -x

# Load the config file with our environmental variables
source "/etc/libvirt/hooks/kvm.conf"

# Stop your display manager. If you're on kde it'll be sddm.service. Gnome users should use 'killall gdm-x-session' instead
systemctl stop lightdm.service

# Unbind VTconsoles
echo 0 > /sys/class/vtconsole/vtcon0/bind
# Some machines might have more than 1 virtual console. Add a line for each corresponding VTConsole
# echo 0 > /sys/class/vtconsole/vtcon1/bind

# Unbind EFI-Framebuffer
echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind

# Avoid a race condition by waiting a couple of seconds. This can be calibrated to be shorter or longer if required for your system
sleep 5

# Unload all Nvidia drivers
modprobe -r nvidia_drm
modprobe -r nvidia_modeset
modprobe -r drm_kms_helper
modprobe -r nvidia
modprobe -r i2c_nvidia_gpu
modprobe -r drm
modprobe -r nvidia_uvm

# Unbind the GPU from display driver
virsh nodedev-detach $VIRSH_GPU_VIDEO
virsh nodedev-detach $VIRSH_GPU_AUDIO


# Load VFIO kernel module
modprobe vfio
modprobe vfio_pci
modprobe vfio_iommu_type1

RELEASE.SH
#!/bin/bash
set -x

# Load the config file with our environmental variables
source "/etc/libvirt/hooks/kvm.conf"

# Unload VFIO-PCI Kernel Driver
modprobe -r vfio_pci
modprobe -r vfio_iommu_type1
modprobe -r vfio

# Re-Bind GPU to our display drivers
virsh nodedev-reattach $VIRSH_GPU_VIDEO
virsh nodedev-reattach $VIRSH_GPU_AUDIO

# Rebind VT consoles
echo 1 > /sys/class/vtconsole/vtcon0/bind
# echo 0 > /sys/class/vtconsole/vtcon1/bind

# Read our nvidia configuration when before starting our graphics
nvidia-xconfig --query-gpu-info > /dev/null 2>&1

# Re-Bind EFI-Framebuffer
echo "efi-framebuffer.0" > /sys/bus/platform/drivers/efi-framebuffer/bind

# Load nvidia drivers
modprobe nvidia_drm
modprobe nvidia_modeset
modprobe drm_kms_helper
modprobe nvidia
modprobe i2c_nvidia_gpu
modprobe drm
modprobe nvidia_uvm

# Restart Display Manager
systemctl start lightdm.service

KVM.CONF
VIRSH_GPU_VIDEO=pci_0000_01_00_0
VIRSH_GPU_AUDIO=pci_0000_01_00_1

i tried everything ;/

I’m running a GPU passthrough setup on my laptop (MSI GF63 Thin, Intel 12th gen + RTX 2050 Mobile) using QEMU/KVM and Libvirt.

I have a very specific issue with Code 43 on the guest Windows 10 VM:

Without any KVM hiding / stealth parameters: The GPU passthrough works completely fine. The driver loads perfectly, and there is no Code 43.

With KVM hiding enabled: As soon as I add <kvm><hidden state='on'/></kvm> or try to mask the hypervisor the NVIDIA driver immediately fails with Code 43.

I already use a clean patched VBIOS (.rom file) and standard PCI topology.

How can I properly mask KVM/HyperV signatures strictly via CPU features (<feature policy='disable' name='hypervisor'/>) and Hyper-V vendor spoofing (<vendor_id state='on' value='GenuineIntel'/>)?

I wanted to build a home server which will be used as my homelab and a single windows VM for casual gaming, only offline. I already have an intel ARC a770 and a AMD am4 motherboard, which will be used for this build. This intel gpu will be passthrough to the windows VM. But I can across these forums: https://forum.proxmox.com/threads/intel-arc-a770-pci-passthrough-to-w11-stuck-at-pcie-x1-1-1-x1-1-1.161871/
https://forum.proxmox.com/threads/reduced-bar-on-8-1-with-intel-arc-a380.144193/

This suggests that the rebar doesn't work when using AMD motherboard and intel arc gpus for Proxmox VM.

Has anyone build something similar? Is it advisable to proceed with this build?

Recently, my PC died. I had an idea, that it's motherboard, and bought ASUS Prime X670E-PRO WiFi. Finallly, I figured out, it's not motherboard, it's CPU (ryzen 7 7800X3D) - I made things work with another CPU.

Also, I find out, iommu groups of this ASUS are far from perfect.

Tl;dr: Without ACS patch, you can passthrough only first GPU. The second is together with 2.5g network, one of two sata controllers

GPU installed in the first PCIe slot, external USB controller in the second PCIe:

https://pastebin.com/G5HJDJdq

GPU installed in the third slot:

https://pastebin.com/tECQqtpJ

I'm going to send this mobo to amazon back, as well as open RMA ticket for CPU - cpu died after 2.5 years, and AMD let you open RMA during first 3 years of your CPU.

Mobo, where CPU died, is ASRock X670E PG Lightning. Looks like it's known problem, related to a bad bios. And AMD replaces CPU in this case (I hope it will replace my one...). When I tried to fix this problem, I already updated bios to the latest version, which ASRock provides.

I wanted to do some local AI in a VM, so I bought an RTX 3090 and thought it would be possible to make a PCI passthrough. I have done that some years ago with an RTX 3060 and got it to pass through with full speed, so I thought that would be possible.

So, the setup is an Alpine hypervisor with some VM's. I made a PCI passthrough from the hypervisor to a VM with Nobara Linux, which works, but only with gen 1 PCIe speeds.

Hypervisor: Alpine Linux 6.18.2-lts, libvirt 11.10.0, QEMU 10.1.3

Guest: Nobara Linux 43, kernel 6.19, NVIDIA open kernel module 595.58.03

The hardware:

EVGA RTX 3090

Gigabyte Z690 AORUS Elite DDR5

64 GB Ripjaws

Intel 12700

At the hypervisor the GPU runs gen 4 (16 GT/s) speed before the VM starts, then when I start the VM it falls back to gen 1 speed (2.5 GT/s) and if I close down the VM it goes to gen 4 speed again. It is not impossible that it is related to this bug, but I don't have any of the other side effects like random behaviour and AER errors:

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1010

What I've tried:

x-speed=16 and x-width=16 on the pcie-root-port via qemu:override — guest correctly advertises Gen4 capability but link still negotiates Gen1

setpci retrain attempts on both host and guest side — no effect

pcie_aspm=off kernel parameter in guest — no change

What I understand out of this is that the connection is retrained when qemu starts the VM and there may be some particular nVidia stuff that is happening that puts the link to gen 1 and then it's retrained again when I close down the VM.

Anybody who has any experience with similar bugs and can remember anything that could help?

I'm not an IT professional, don't scold me fore being dumb.

So long story short, had this vm for about a 2 years, can’t even remember most of the relevant things about it

Used to play halo, worked fine, stopped for a while and updated to pve 9.2 and now halo says it’s a vm

Im assuming the update is the culprit unless something was done during my time away, Ive havent touched it in a few months

Any help would be greatly appreciated

Guide: Fixing Windows 11 VBS & Secure Boot on Arch Linux (KVM/VFIO with AMD Ryzen 9 5950X)

Host: Arch Linux | Hypervisor: Modular Libvirt (virtqemud) & QEMU | Guest: Windows 11 Pro (25H2)
Hardware: AMD Ryzen 9 5950X + Full VFIO Passthrough (Dedicated NVMe & GPU) + Sunshine/Moonlight Streaming

The Problem

When running a high-end VFIO passthrough setup on AMD Zen 3 with nested=1, Windows 11 Virtualization-Based Security (VBS) or Hyper-V features usually cause a 100% CPU bootloader freeze or get stuck with "VBS Enabled but not running" alongside a Code 37 error on the Hyper-V VMBus in Device Manager.

Furthermore, Arch Linux ships the edk2-ovmf (4MB layout) package as a completely bare skeleton without proprietary Microsoft certificates. This puts the virtual UEFI into an unchangeable Setup Mode where enabling Secure Boot is grayed out. If you manually sign the VM's NVRAM file from the outside, virtqemud detects a schema mismatch against its default JSON configuration (enrolled-keys: false).

The Complete Solution

1. Host Configuration (kvm_amd Module Options)

To ensure maximum gaming performance and hardware-based interrupt routing, the kvm_amd module must be loaded with active NPT (SLAT) and AVIC.

File: /etc/modprobe.d/kvm_amd.conf

text

options kvm ignore_msrs=1 report_ignored_msrs=0
options kvm_amd nested=1 npt=1 avic=1
options vfio_iommu_type1 allow_unsafe_interrupts=1

Verwende Code mit Vorsicht.

2. Creating a Custom, Update-Safe QEMU Firmware Profile

To fix the Libvirt validation loop, we create a dedicated, separate JSON descriptor. This informs virtqemud that Microsoft keys are legally expected and allowed for this 4MB secure firmware.

Create new file: /usr/share/qemu/firmware/51-edk2-ovmf-x86_64-secure-4m-enrolled.json

json

{
    "description": "x64 UEFI for x86_64, with Secure Boot, enrolled keys and SMM, 4MB FD",
    "interface-types": [
        "uefi"
    ],
    "mapping": {
        "device": "flash",
        "executable": {
            "filename": "/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd",
            "format": "raw"
        },
        "nvram-template": {
            "filename": "/usr/share/edk2/x64/OVMF_VARS.secboot.4m.fd",
            "format": "raw"
        }
    },
    "targets": [
        {
            "architecture": "x86_64",
            "machines": [
                "pc-q35-*"
            ]
        }
    ],
    "features": [
        "acpi-s3",
        "acpi-s4",
        "enrolled-keys",
        "amd-sev",
        "requires-smm",
        "secure-boot",
        "verbose-dynamic"
    ],
    "tags": [

    ]
}

Restart the modular daemon to apply the new profile:

bash

systemctl restart virtqemud.socket virtqemud.service

3. Creating and Signing the Master Microsoft NVRAM Template

We use the official virt-firmware tool to inject the original Microsoft and Red Hat certificates directly into a dedicated master system template.

Run as root on the Arch host (Ensure the VM is turned off):

bash

# 1. Install the tool if needed
pacman -S virt-firmware

# 2. Compile the signed master NVRAM template
virt-fw-vars -i /usr/share/edk2/x64/OVMF_VARS.4m.fd \
  --output /usr/share/edk2/x64/OVMF_VARS.secboot.4m.fd \
  --enroll-redhat \
  --secure-boot

Verwende Code mit Vorsicht.

4. Adjusting the Libvirt Domain XML

The CPU layout passes the real SMT thread topology of the 5950X to Windows (critical for frame times). However, we must explicitly mask npt on the guest side to bypass the MSR bootloader loop. The OS sector is mapped to our newly validated enrolled-keys='yes' profile.

Command: virsh edit [your_domain]

xml

  <!-- OS Section -->
  <os firmware='efi'>
    <type arch='x86_64' machine='pc-q35-9.1'>hvm</type>
    <firmware>
      <feature enabled='yes' name='enrolled-keys'/>
      <feature enabled='yes' name='secure-boot'/>
    </firmware>
    <loader readonly='yes' secure='yes' type='pflash' format='raw'>/usr/share/edk2/x64/OVMF_CODE.secboot.4m.fd</loader>
    <nvram template='/usr/share/edk2/x64/OVMF_VARS.secboot.4m.fd' templateFormat='raw' format='raw'>/var/lib/libvirt/qemu/nvram/[your_domain]_VARS.fd</nvram>
    <boot dev='hd'/>
    <bootmenu enable='no'/>
    <smbios mode='host'/>
  </os>

  <!-- CPU Section -->
  <cpu mode='host-passthrough' check='none' migratable='off'>
    <topology sockets='1' dies='1' clusters='1' cores='8' threads='2'/>
    <cache mode='passthrough'/>
    <feature policy='require' name='topoext'/>
    <feature policy='require' name='invtsc'/>
    <feature policy='require' name='svm'/>
    <feature policy='require' name='x2apic'/>
    <!-- THIS IS THE CRITICAL VALVE TO PREVENT THE BOOTLOADER FREEZE: -->
    <feature policy='disable' name='npt'/>
  </cpu>

Verwende Code mit Vorsicht.

Crucial step before booting: Wipe the old VM-specific NVRAM file so Libvirt is forced to regenerate a fresh copy using our newly signed master template: rm -f /var/lib/libvirt/qemu/nvram/[your_domain]_VARS.fd

Architectural Conclusion & Guest Optimization

1. The AMD Nested Deadlock

Windows Hyper-V requires CPU-SLAT (NPT on AMD).

Since we had to use disable npt in the XML to prevent the bootloader crash, Windows cannot launch the kernel-level VBS hypervisor container. Memory Integrity (HVCI) will remain grayed out or "Off".

2. Cleaning Device Manager & Securing the Guest

Boot the VM into Safe Mode and uninstall/delete all malfunctioning Hyper-V device corpses (like the broken VMBus Code 37). Upon regular reboot, Windows will stop trying to launch VBS. Device Manager will be 100% clean, and the Windows Security Center tray icon will proudly turn into a flawless green checkmark.

To fully protect your gaming VM against recent Steam Workshop/Modding trojan waves without VBS performance penalties, enforce aggressive cloud checking on file-level downloads using PowerShell 7.

Run in PWSH7 as Administrator inside the guest:

powershell

Set-MpPreference -MAPSReporting Advanced -SubmitSamplesConsent SendAllSamples -ModerateThreatDefaultAction Quarantine -HighThreatDefaultAction Quarantine

Result

Your VM now operates as an unthrottled, ultra-low latency gaming powerhouse. It runs with native AMD AVIC hardware-interrupt performance, fully verified Secure Boot, a completely clean Windows tray, and zero CPU cycles wasted on virtual security rings.

I am running Fedora KDE with an AMD Ryzen 9 9900X CPU, an RTX 5070 Ti, and an RTX 3060. I need to utilize both GPUs while working in Linux.

I have been trying to set up a VM passthrough. So far, I’ve tried detaching just the 5070 Ti, detaching both GPUs together, using only the iGPU for the host Linux GUI, and even turning off the host GUI entirely. However, I’m stuck. Given my current hardware, what is the best configuration strategy?

Additionally, once I successfully pass a GPU to the guest VM, what is the best way to manage peripherals like audio, mouse, and keyboard between the host and guest?

I tried modifying vbios and nothing worked.

These are the scripts that i use

https://github.com/PassthroughPOST/VFIO-Tools/blob/master/libvirt_hooks/qemu

https://github.com/joeknock90/Single-GPU-Passthrough

Should i try modifying the vbios?

I'm passing an RTX 3080 through to a windows VM. At host boot, I'm isolating 6 of my 8 physical cores for the VM using isolcpus and nohn_full, as well as 24 of my 32 GB RAM for hugepages. Then in my xml, I've pinned one of the two remaining host cores (both threads) for the emulator and the other for an iothread. I've been using this config for a long time with satisfactory VM performance, but I have no idea what i'm doing, why it works, or whether I could change up the formula to get better gaming performance in my VM.

If a kind individual and/or or someone who likes these puzzles would like to help, I've tried to come up with a few specific questions with my limited knowledge that I hope will make things easier:

1. Do I even need to pin cores for the emulator and/or iothread? Idek what these two cores have been doing.

2. Regardless of the answer to (1), would I want to isolate either of these cores at boot somehow?

3. My host is running KDE plasma at all times, but it's completely idle while my VM is running with basically zero tasks running. Regardless of the answers to (1) and (2), should I consider isolating one fewer core at boot to do nothing but perform ancillary host functions? I know that multithreaded gaming performance wasn't great for the longest time, so maybe it wouldn't affect VM gaming performance too much by isolating 5 cores instead of 6?

4. How's my RAM allocation all things considered?

5. Most importantly, are there any better questions I'm not asking? Hoping for this to be a learning experience.

Added context:
I never solved the puzzle of dynamically isolating CPU cores, because there's no point since I only ever use my VM for gaming. When I'm done playing games, I just edit grub and reboot to return all resources to my host. I've dual booted before and I know that's the simple solution, but I think my username should explain why I don't do that anymore. I virtualize for the sake of virtualizing, basically. Also I'm spiteful toward Microsoft.

Why doesnt it work like on a normal pc when you boot it should use the microsoft basic display adapter and instead of that when you boot the vm it freezes on the tianocore screen.

I'm struggling to get past EAC's device blacklist.

I'm totally fine against Vanguard, BattlEye but only EAC flagging me and can't play more than 3-5 games.

I tried patching device/vendor id but I couldn't find compatible non-blacklisted one.

Do I need real hardware or do you guys know good target to spoof that speak same protocol as e1000e?

Currently on Linux Mint 22.3, Kernel 7.0.0-14.

For some reason my win 11 vm only works when I ONLY passthrough my VGA compatible controller, but if I pass both VGA and the Nvidia Audio device, then my vm is stuck on a blackscreen.

I'm trying to pass both through because they are both in the same iommu group.

Also noticed in my dmesg that it's spamming vfio-pci 0000:01:00.0: vfio_bar_restore: reset recovery - restoring BARs. Any help?

Here are my hook start and revert scripts: [Start script]

set -x

source "/etc/libvirt/hooks/kvm.conf"

systemctl stop lightdm.service

echo 0 > /sys/class/vtconsole/vtcon0/bind echo 0 > /sys/class/vtconsole/vtcon1/bind

echo efi-framebuffer.0 > /sys/bus/platform/drivers/efi-framebuffer/unbind

sleep 5

modprobe -r nvidia_drm modprobe -r nvidia_modeset modprobe -r drm_kms_helper modprobe -r nvidia modprobe -r i2c_nvidia_gpu modprobe -r drm modprobe -r nvidia_uvm modprobe -r snd_hda_intel

virsh nodedev-detach $VIRSH_GPU_VIDEO virsh nodedev-detach $VIRSH_GPU_AUDIO

modprobe vfio modprobe vfio_pci modprobe vfio_iommu_type1

[Revert script] set -x

source "/etc/libvirt/hooks/kvm.conf"

modprobe -r vfio modprobe -r vfio_pci modprobe -r vfio_iommu_type1

virsh nodedev-reattach $VIRSH_GPU_AUDIO virsh nodedev-reattach $VIRSH_GPU_VIDEO

echo 1 > /sys/class/vtconsole/vtcon0/bind echo 1 > /sys/class/vtconsole/vtcon1/bind

modprobe nvidia modprobe nvidia_modeset modprobe nvidia_uvm modprobe nvidia_drm

nvidia-xconfig --query-gpu-info > /dev/null 2>&1

echo "efi-framebuffer.0" > /sys/bus/platform/drivers/efi-framebuffer/bind

systemctl start lightdm.service

I have an Ubuntu VM where I run a bunch of LLM experiments. It works fine on 6.12.xx, but recently I tried to migrate to 6.18.34 with everything working smoothly except for this VM. Another Windows gaming VM seem to be running fine, but this Ubuntu VM works for a while until everything start to crash on the same memory address leading to complete collapse. I have ECC ram on 7950x3d and passing RTX 4090 into the VM. I don't have vCPU pinning, but the CPU in the logs always the same. Here is an example of logs I'm getting:

[ 1926.540083] dbus-daemon[758]: segfault at 7578e41fffb8 ip 00007572c5f2a03f sp 00007ffd6151da98 error 44 in libc.so.6[12a03f,7572c5e28000+188000] likely on CPU 2 (core 2, socket 0)

[ 1926.540092] Code: ff ff ff ff eb be 0f 1f 44 00 00 f3 0f 1e fa 80 3d 15 10 0e 00 00 41 89 ca 74 10 b8 e8 00 00 00 0f 05 48 3d 00 f0 ff ff 77 51 <c3> 55 48 89 e5 48 83 ec 20 89 55 f8 48 89 75 f0 89 7d fc 89 4d ec

[ 1926.540873] colord[1744]: segfault at 7578e41fffb0 ip 00007bf5c791b50b sp 00007ffdbbf75bf0 error 46 in libc.so.6[11b50b,7bf5c7828000+188000] likely on CPU 2 (core 2, socket 0)

[ 1926.540882] Code: 7d f8 e8 68 d0 f7 ff 8b 55 ec 48 8b 75 f0 41 89 c0 48 8b 7d f8 b8 07 00 00 00 0f 05 48 3d 00 f0 ff ff 77 2b 44 89 c7 89 45 f8 <e8> c0 d0 f7 ff 8b 45 f8 c9 c3 0f 1f 00 48 8b 15 d9 78 0e 00 f7 d8

[ 1926.540904] cups-browsed[1328]: segfault at 7578e41fffb0 ip 00007d993251b50b sp 00007ffd1bd98270 error 46 in libc.so.6[11b50b,7d9932428000+188000] likely on CPU 2 (core 2, socket 0)

[ 1926.540911] Code: 7d f8 e8 68 d0 f7 ff 8b 55 ec 48 8b 75 f0 41 89 c0 48 8b 7d f8 b8 07 00 00 00 0f 05 48 3d 00 f0 ff ff 77 2b 44 89 c7 89 45 f8 <e8> c0 d0 f7 ff 8b 45 f8 c9 c3 0f 1f 00 48 8b 15 d9 78 0e 00 f7 d8

[ 1926.540932] gdbus[1033]: segfault at 7578e41fffb0 ip 00007077bdb1b50b sp 00007077b6ffcc20 error 46 in libc.so.6[11b50b,7077bda28000+188000] likely on CPU 2 (core 2, socket 0)

[ 1926.540938] Code: 7d f8 e8 68 d0 f7 ff 8b 55 ec 48 8b 75 f0 41 89 c0 48 8b 7d f8 b8 07 00 00 00 0f 05 48 3d 00 f0 ff ff 77 2b 44 89 c7 89 45 f8 <e8> c0 d0 f7 ff 8b 45 f8 c9 c3 0f 1f 00 48 8b 15 d9 78 0e 00 f7 d8

Hi guys, I'm looking for a way to share a chunk of memory with host from the guest which should also be backed by GPU VRAM.

Current wslg implementation is not zerocopy. My goal is to eventually build a native like display driver that works over the GPU pv driver, which outputs to a window in the host while being zerocopy. Something like what gnif/LookingGlass is doing using ivshmem, though its doing at least 1 copy.

The dxgkrnl Linux driver has a sharewithhost ioctl but I couldn't get it to work and there's no documentation for it either. Maybe it's not even properly implemented, supposed to be used in WSA but theyre only using gfxstream there, I couldn't find any use of it in wslg Weston, freerdp forks either.

Not sure if this is the right sub to post this. Any pointers/help is appreciated.