I have first tried having my top slot gpu as my primary and the bottom one as secondary (which I tried to hide from dom0 but failed) then I tried the other way around to have my bottom slot gpu as my only display out and the top one to be hidden but still getting the same error.
I’m very curious to get the perspective of other people that managed to get GPU passthrough working and if they encountered similar behavior to mine.
It probably try to use the GPU you just hide from dom0.
Assuming you used the correct value for rd.qubes.hide_pci:
- Only plug your primary GPU to your primary screen.
- Once you successfully booted into Qubes, plug the secondary GPU to the secondary screen
Also did you checked my comment about this subject
Note: if after this step when you reboot the computer you get stuck in the QubesOS startup that means you are trying to use the GPU you just hide. Check your BIOS options. Also check the cables, BIOS have some GPU priority based on the type of cable. For example, DisplayPort can be favoured over HDMI.
I am in this exact same situation, but in my case:
- I am also on Qubes 4.2 (rc4)
- My CPU has integrated graphics
- I’m trying to hide an Nvidia GPU
I had a previous setup working on 4.1 with the same extra boot parameters. So my hypothesis is that rd.qubes.hide_pci is not working as expected in Qubes 4.2.
What makes it particularly challenging to debug is that when I switch to another tty to get access to a console, it moves back to tty1 after half a second or so. So I can never login and see debugging information.
Are you suggesting GPU hot-plugging?
no:
- Both GPU correctly plugged in their respective PCI slots
- Only connect 1 cable, from the primary GPU to the primary screen
That way you physically ensure that if you have something on your screen then it come from the primary GPU. Should be easier to debug that way
1 Like
Yes, these are the exact steps I followed from the beginning and as I said above I get to write in my LUKS password after other stuff loads I get stuck with the lightdm.service error .
To be sure I wasn’t doing something wrong I also switched between the output of my 2 GPUs. Once I tried with top slot gpu as primary (plugged in the monitor) and the second one hidden and then the other way around but still got the same error!
Would it be a viable option to downgrade to 4.1 to try it out and see if it works?
1 Like
weird, out of curiosity, if in the grub, on the xen line, you add the parameter x2apic_phys=true , do you see any difference ?
OK. Then this is my situation already with the integrated graphics.
Still the same for me, unfortunately.
Turns out lightdm trying to start was the source of this issue. In tty2 I ran the command sudo systemctl stop lightdm after fighting the system and it stopped.
Right so I tried running x2apic_phys under the command line option of xen but still getting the same outcome.
I have tried downgrading to 4.12 but when I boot into the .iso I get “A start job is running for udev Wait for Complete Device Initialization 1 min / 3 min 4s” then nothing commences further than that.
Is there any type of issue related to lightdm.service open on github?
I inspected the error log for lightdm on my system and what caused it to fail was Xorg. So the issue is with Xorg, I think.
Somehow it’s still trying to use the secondary graphics card even through technically it should be hidden
I have managed to get pass the rd.qubes.hide_pci part of the guide the only problem is that I had to downgrade to 4.12 .
I suspect that something got broken in 4.2 .
I was able to pass through my GPU without even hiding it using boot parameters by just configuring the correct GPU to boot Xorg on. Since I’m using my iGPU for Qubes, the config file is this:
vim /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Driver "Intel"
Option "DRI" "3"
EndSection
I think this might fix your situation. If it doesn’t work, you can simply just delete the 20-intel.conf file you created and go back to normal.
1 Like
Would this be the same for a dual AMD gpu setup?
Of course with the identifier and driver changed to AMD I guess.
I don’t have an AMD GPU to test right now, but I’d assume it would work like this:
/etc/X11/xorg.conf.d/20-amdgpu.conf
Section "Device"
Identifier "AMDGPU1"
Driver "amdgpu"
BusID "PCI:1:0:0" # Replace this with the actual BusID of your GPU for Qubes
EndSection
The driver may be something else on Qubes, in which case you can check by using lspci -vnn and looking for your VGA compatible controller AMD device. The driver name will be in the “Kernel modules” or “Kernel driver in use” sections.
For the BusID, you’re going to need to find which of the AMD GPUs you want to keep on Qubes, which will be the number before the “VGA compatible controller” on that device.
1 Like
Nice! However in this case can you still pass it through to a VM? Id’s suspect no since it’s in use by dom0 bur I may be wrong.
I somehow managed to boot with rd.qubes.hide_pci but the problem now is that when I start the gpu_HVM I get: “Guest has not initialized the display (yet)”. I’ve looked into this and someone was claiming that I should get an older firmware .bin file from 4.1 and replace it in 4.2 but the problem is that these files are the exact same and behavior doesn’t change.
Happy to hear. You don’t happen to know what made it work, correct?
Yes I can, and I go from seeing the qubes startup log on the monitor to seeing my HVM whenever I boot it. I’m surprised it works but it does haha. Might just be a case of me being lucky and my GPU model just working for some reason.
1 Like