Assigning device to a qube leads to another device nonassignable

First of all, it is not related to the other issue I have, That device isn’t assignable by itself.

Namely, when I assign a device to a qube (HVM, of course), the other device becomes nonassignable, which is checked executing
$ sudo xl pci-assignable-list

Devices aren’t in the same iommu_group, so that is not the cause. Actually, the device that is assigned (that way causing the other one to become nonassignable) isn’t even found in IOMMU_group, but it works flawlessly in Qubes, assigned or not???

Obviously, they share something that makes the other one nonassignable when the other is assigned. What that could be? IRQ, or something else, and if so…

... any point to a resource to read and learn would me more than enough and appreciated.

I couldn’t find any info on this, so thanks for even reading this.

Bump

Make sure that devices are effectively using only one function.
If I’m unclear, think about the example of a GPU device, which has 2 functions : video + audio.
I think you cannot PT one function w/o the other.

Well. I must admit that reading this doesn’t help to resolve the confusion, especially knowing that we are already provided with the possibility of separated sys-audio and sys-gui.

Well, while trying to be private as possible not to disclose which devices are in the matter but to get the help, I can only tell that they don’t have anything in common, and have absolutely different functions, like vga and usb-wifi for example, so assigning wifi to sys-usb makes vga nonassignable.

I may be wrong, but I guess this possibility is reserved to desktop users, who for the most part have a separate audio card on the MoBo, in addition to the audio of the GPU. I admit I never tried to PT one w/o the other.

I don’t know what you mean by that. All devices should be in a IOMMU group afaik.

Then, not easy to help w/o information … Just provide it redacted. Change brands, drivers, PCI ids, etc.
Kernel driver/module used ? Are you sure the PCI ids are correct in the kernel hide command line ? Are you effectively hiding them all ? Is the syntax correct ?
Maybe your platform isn’t well supported ? Needs PCI quirks, no-strict-reset, permissive mode, etc ? BIOS update ? What do logs say ? Do you try the “-v” switch when using xl commands ?
So many things could go wrong ^^

But I’d also like to know how the qubes handling/commands are different from Xen ones.
I guess it’s done so, so they can eventually move away from Xen w/o rewriting everything, but imo it just adds confusion (at least for ppl like me coming from vanilla Xen).
For instance, what happens when you select a device in the Devices tab of the qubes manager, and then you delete the corresponding Qube ? How is the device handled then ?

I found a bit of information there : qubes.devices – Devices — core-admin mm_203ee458-0-g203ee45-dirty documentation, but it’s meant for devs, not sysadmins ^^
When qubes.xml is mentionned, it’s /var/lib/qubes/qubes.xml, it has all information about the domUs, libvirt style. Try to find some information from the blocks of each domU.
Also, I’ve found in man qvm-pci that there is a “persistent” option when attaching.

Hey @Sven, can you check this for me, please.

When your sys-usb express card is up, when you run

[user@dom0 ~]$ sudo xl pci-assignable-list

is BDF of your internal GPU listed there? If not, can you shut down named sys-usb and check again.

I’m asking because that is happening with me, which makes it hard to create sys-gpu. I’d have to live without express card…

Thanks in advance.

My express card (forth USB controller) is not assinged to sys-usb but a specific qube called work-dev. When it’s up sudo xl pci-assignable-list only shows my Ethernet controller and one other USB controller assigned to a qube that’s not running. When work-dev is down, the express card is listed as expected.

My GPU never shows up in that list, but I am also not using sys-gui (if that makes a difference).

[user@dom0 ~]$ qvm-pci
BACKEND:DEVID  DESCRIPTION                                                                                     USED BY
dom0:00_00.0   Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller                           
dom0:00_02.0   VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller         
dom0:00_14.0   USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller  work-web (no-strict-reset=true)
dom0:00_16.0   Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1      
dom0:00_19.0   Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville)          
dom0:00_1a.0   USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2  sys-usb (no-strict-reset=true)
dom0:00_1b.0   Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller   
dom0:00_1c.0   PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1              
dom0:00_1c.1   PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2       
dom0:00_1c.2   PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3       
dom0:00_1d.0   USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1  sys-usb (no-strict-reset=true)
dom0:00_1f.0   ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller                               
dom0:00_1f.2   SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode]   
dom0:00_1f.3   SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller                          
dom0:01_00.0   SD Host controller: Ricoh Co Ltd PCIe SDXC/MMC Host Controller                                  
dom0:02_00.0   Network controller: Intel Corporation Wireless 7260                                             sys-wifi
dom0:03_00.0   USB controller: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller                      work-dev
[user@dom0 ~]$ sudo xl pci-assignable-list
0000:00:19.0
0000:00:14.0
[user@dom0 ~]$ qvm-shutdown --wait work-dev
[user@dom0 ~]$ sudo xl pci-assignable-list
0000:03:00.0
0000:00:19.0
0000:00:14.0

Thanks for a quick response.
Well, after ten months of not checking until saw your post there, it looks like there’s no vga listed or not as assignable for me too anymore. Now I’m even not sure in my sanity that it was ever there, although I think it should be there so it could be passthrough-ed to sys-gpu.