I’m on latest Qubes 4.0 release, kernel 5.4.143 and 5.4.156
I’ve been using the kernel parameter “xen-pciback.hide=(01:00.0)” since months for my PCIe USB 3.0 VIA card which I pass through to a Windows 10 HVM. This has worked flawlessly ever since.
Two days ago, I decided to use USB VM for an additional security layer.I proceeded as described here:
USB qubes | Qubes OS and used “sudo qubesctl state.sls qvm.sys-usb”. My USB keyboard also worked perfectly on LUKS, all good.
Naturally, the USB VM also grabbed the VIA card - it shows up under the USB VM “Devices”.
That is a bit unfortunate - I had hoped that Qubes would check the kernel parameter and see that it shouldn’t touch the card due to the “hide”, but ok, not a bug but maybe a feature.
I then disabled “start … on boot” for the USB VM, rebooted and removed the VIA card from the “Devices”. Again a reboot, manual start of the USB VM and a few seconds later all USB devices worked again - great!
However, Windows no longer sees the VIA card…
I’d be happy to sacrifice the USB VM for the time being / to help in isolating the root cause, but right now I’d like to know how I can resolve this asap as without the device in Windows I’d need to install Windows on another SDD (very much not desired).
I don’t have old logs, but the VIA card is now taken over by dom0 it seems (I am sure I did not see this before creating the USB VM):
0.000000] Command line: root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-…7 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 quiet plymouth.ignore-serial-consoles xen-pciback.hide=(01:00.0)
[ 0.510175] Kernel command line: root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-…7 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 quiet plymouth.ignore-serial-consoles xen-pciback.hide=(01:00.0)
[ 0.734460] pci 0000:01:00.0: [1106:3483] type 00 class 0x0c0330
[ 0.734490] pci 0000:01:00.0: reg 0x10: [mem 0xfcf00000-0xfcf00fff 64bit]
[ 0.734604] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 4.048207] pciback 0000:01:00.0: seizing device
[ 234.734859] xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0
[ 234.735200] pciback 0000:01:00.0: registering for 7
[ 279.294512] pciback 0000:01:00.0: Driver tried to write to a read-only configuration space field at offset 0x6, size 2. This may be harmless, but if you have problems with your device:
I guess this was starting Windows (fail, PCI device not seen):
[ 9812.655494] xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0
[ 9812.657660] pciback 0000:01:00.0: registering for 12
Starting Linux (works, PCI device seen):
[10999.707621] xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0
[10999.708939] pciback 0000:01:00.0: registering for 14
Again Windows:
[11645.385310] xen_pciback: vpci: 0000:01:00.0: assign to virtual slot 0
[11645.385984] pciback 0000:01:00.0: registering for 16
This “vpci/virtual slot” looks very strange to me…
My guess is that “qvm.sys-usb” also made some other changes for dom0 Xen which I cannot undo/don’t know how to undo?
Side note: I tried to install the Windows Qubes Tools right after installing Windows, but I cannot get all Xen drivers installed (hangs) so I’ve given up on that.