3.5 GB Patch (GPU PassThrough) Question

Hello, there!
I’d like to know what the “^” (Caret) Symbol does. Its in the 3.5 GB RAM Patch (stubroot init file) where only Qubes should be affected by the patch, if their names start by
Within the Patch it says ‘^gpu_’
So, anybody knows, what the caret is for? 'Cause somehow its not working… If I attach GPU with more than 2.5 GB there is only Black Screen on boot.
Thanks for your time!

You VM name should start with “gpu_” for patch to work for it.
If you’re on current-testing then the patch doesn’t work for xen-hvm-stubdom-linux and xen-hvm-stubdom-linux-full with latest version 1.2.4-1.fc32. You need to downgrade it to version 1.2.3-1.fc32 and apply patch for downgraded version:

Hey, @tzwcfq I tried the downgrade, you suggested on the other thread. But had no luck, to be honest. Black Screen on HVM boot, with GPU attached.
Must seem to you that I just would’nt listen to you. That’s not the case. I tried “everything” I could get my hands on, but no success yet.
Thanks for the regex explanation!
And I’ll keep trying! :slightly_smiling_face:

What GPU are you trying to passthrough?
I’ve successfully passthrough my NVIDIA GeForce GT 1030.
Maybe there are some problems with newer GPUs.
At this point I can only suggest you to recheck that you did everything according to the guide and didn’t mix up GRUB update for BIOS/UEFI, patching for Qubes R4.0/Qubes R4.1 etc:

@tzwcfq Thanks a lot for your effort! Really!!
I will do.
My CPU is Ryzen7 3700X, MB X570 Gaming X, 32GB RAM, one fast m.2 for Qubes and one really fast m.2 for Windows HVMs.
Best regards, Jo

AAAAnd the GPU is Nvidia GTX 970 :slightly_smiling_face:

Now trying again your setup @tzwcfq :
Formerly all attempts were made with UEFI installation.
Now switched to BIOS. Qubes 4.1 Testing Repos enabled and updated.
Kernel latest (5.17.7-1.fc32 mistake?)
Downgraded xen-hvm-stubdom-linux and …linux-full to version 1.2.3-1.fc32
Installed the 3.5 GB patch in Stubroot init file.
Modified grub: added: rd.qubes.hide_pci=0a:00.0,0a:00.1 (and added at the end of the line nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:0ff
(about to try without - again)
For testing I made Windows HVM with only 2800MB RAM.
But trying to install latest Nvidia drivers fails. Video TDR failure.
I started in secure mode and installed the drivers for GPU and Audio by Device Manager and the Nvidia drivers.
Start: TDR Failure

Hints very welcome, I’ll keep trying. :slightly_smiling_face:

I’ve only tried on kernel 5.17.5-1.fc32 and didn’t try with kernel 5.17.7-1.fc32 as it doesn’t work correctly with my hardware.
I had the same black screen issue and error with xen-hvm-stubdom-linux and …linux-full 1.2.3-1.fc32 and without patch applied:

If I use xen-hvm-stubdom-linux/xen-hvm-stubdom-linux-full 1.2.3-1.fc32 without patch applied, HVM with 4 GB RAM, with PCI GPU attached - it start to boot with black screen then it fails with this error:
dom0 qubesd[3557]: vm.gpu_win10: Start failed: qrexec-daemon startup failed: 2022-05-07 12:27:56.268 qrexec-daemon[44408]: qrexec-daemon.c:135:sigchld_parent_handler: Connection to the VM failed
and in /var/log/libvirt/libxl/libxl-driver.log :

libxl: libxl_pci.c:1489:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:01:00.1
libxl: libxl_pci.c:1484:libxl__device_pci_reset: write to /sys/bus/pci/devices/0000:01:00.0/reset returned -1: Inappropriate ioctl for device

But GPU worked fine for me with xen-hvm-stubdom-linux and …linux-full 1.2.3-1.fc32 and without patch applied but 3 GB ram.


Uffffff! I managed it!

  1. Multimonitorsetting(?): do as described here:
    GUI configuration | Qubes OS

  2. I forgot, or overlooked this part of the 3.5 GB Patch:

find . -print0 | cpio --null -ov
–format=newc | gzip -9 > …/qemu-stubdom-linux-rootfs
sudo mv …/qemu-stubdom-linux-rootfs /usr/lib/xen/boot/

It looks, as if it was only for Qubes 4.0 BUT its NOT!

Only adapt the naming regarding qemu:

mkdir stubroot
cp /usr/libexec/xen/boot/qemu-stubdom-linux-rootfs stubroot/qemu-stubdom-linux-rootfs.gz
cd stubroot
gunzip qemu-stubdom-linux-rootfs.gz
cpio -i -d -H newc --no-absolute-filenames < qemu-stubdom-linux-rootfs
rm qemu-stubdom-linux-rootfs
nano init

Then modify the init file as every time before… and the magic happens in part 2. of this answer.

I’m a very happy Qubes User right now! Regards to everyone!

1 Like

HI, there! The HVM broke by adding:

[user@dom0 ~] $ qvm-features <VMname> audio-model ich9
[user@dom0 ~] $ qvm-features <VMname> stubdom-qrexec 1
[user@dom0 ~] $ qvm-features <VMname> timezone localtime

Don’t know yet, which one it was…

I have the same qvm-features and it works for me. But I have QWT installed so maybe it’s because of it.
If you delete these features will HVM work again for you?


I actually had QWT installed, too, and it worked before adding the features. Did not know how to remove them, instead of only changing values.
Restored a backup, installed QWT, and its working again.

Still experimenting… :slight_smile:

You can remove them with:

qvm-features -D <VMname> audio-model
1 Like