So I’m upgrading to 4.3 from 4.2 and while I was at it updated my motherboard BIOS and noticed the qvm-device pci list looks entirely different now.
I checked over the 4.3 release notes and while I didn’t see information about this I did see one of the images show with a pci device having a similar scheme (dom0:00_1c.3-00_00.0). It’s very different from what I used in 4.2 and which was similar to the lspci output.
I wouldn’t be surprised to find out that my motherboard is doing something to make these names especially long but the core question is why? What is it trying to tell me?
I didn’t find anything on the forums either but I suspect that’s more me not thinking up good search terms. Please post a link if you know of a thread.
Here’s a some of the qvm-device pci list output
dom0:00_01.2-00_00.0 PCI_Bridge: Advanced Micro Devices, Inc. [AMD] Matisse Switch Upstream
dom0:00_01.2-00_00.0-00_03.0 PCI_Bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
dom0:00_01.2-00_00.0-00_03.0-00_00.0 PCI_Bridge: ASMedia Technology Inc. ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
dom0:00_01.2-00_00.0-00_03.0-00_00.0-00_01.0 PCI_Bridge: ASMedia Technology Inc. ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
dom0:00_01.2-00_00.0-00_03.0-00_00.0-00_01.0-00_00.0 Network: Intel Corporation Wi-Fi 6 AX200 sys-net (attached)
dom0:00_01.2-00_00.0-00_03.0-00_00.0-00_03.0 PCI_Bridge: ASMedia Technology Inc. ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
dom0:00_01.2-00_00.0-00_03.0-00_00.0-00_05.0 PCI_Bridge: ASMedia Technology Inc. ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
dom0:00_01.2-00_00.0-00_03.0-00_00.0-00_05.0-00_00.0 Network: Intel Corporation I211 Gigabit Network Connection sys-net (attached)
dom0:00_01.2-00_00.0-00_03.0-00_00.0-00_07.0 PCI_Bridge: ASMedia Technology Inc. ASM1184e 4-Port PCIe x1 Gen2 Packet Switch
dom0:00_01.2-00_00.0-00_08.0 PCI_Bridge: Advanced Micro Devices, Inc. [AMD] Matisse PCIe GPP Bridge
dom0:00_01.2-00_00.0-00_08.0-00_00.0 Non-Essential Instrumentation: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
See what major version of the Linux kernel was in Qubes 4.2 and what is in Qubes 4.3. The real answer is most likely in the Linux kernel’s release notes.
Zrubi
February 3, 2026, 8:57pm
3
it is part of the release notes:
Major features and improvements since Qubes 4.2: Dom0 upgraded to Fedora 41 (#9402)., Xen upgraded to version 4.19 (#9420)., Default Fedora template upgraded to Fedora 42 (Fedora TemplateVMs and St...
Especially referencing these github issues:
opened 05:25AM - 03 Nov 23 UTC
closed 02:26AM - 16 Apr 25 UTC
C: core
P: default
pr submitted
r4.3-host-cur-test
targets-4.3
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
###… The problem you're addressing (if any)
PCI devices are currently assigned via bus/slot/function, which is not a stable identifier.
### The solution you'd like
Use PCI paths instead, which are much more likely to be stable.
Specifically, replace the "bus" part with the bridges path starting from bus 0. For example:
```
# lspci -t
-[0000:00]-+-00.0
+-00.2
+-01.0
+-02.0
+-02.2-[01]----00.0
+-02.4-[02]----00.0
+-03.0
+-03.1-[03-61]--
+-04.0
+-04.1-[62-c0]--
+-08.0
+-08.1-[c1]--+-00.0
| +-00.1
| +-00.2
| +-00.3
| +-00.4
| +-00.5
| \-00.6
...
```
The device `0000:c1:00.0` is behind bridge at `0000:00:08.1`. In some cases there may be more bridges. There may be more devices behind a single bridge (in the example above it's just a single multi-function device).
You can get bus ranges handled by a given bridge by looking at "secondary" and "subordinate" attributes on lspci (and similarly in sysfs):
```
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Phoenix Internal GPP Bridge to Bus [C:A] (prog-if 00 [Normal decode])
Subsystem: Device 0006:f111
Flags: bus master, fast devsel, latency 0, IRQ 106
Bus: primary=00, secondary=c1, subordinate=c1, sec-latency=0
...
```
I imagine the path for the `0000:c1:00.0` device would look something like this: `0000:00:08.1-00:00.0`, where the `-00` part means "the first bus behind this bridge". The important part is to _not_ include "c1" in the address (but use the address relative to the bridge range), because if the bus will get renumbered (when somebody plugs some other devices for example), that number may change.
If there would be device at bus 5, (which is the third bus behind bridge at 00:03.1), for example at 0000:05:01.5, it would have a path like `0000:00:03.1-02:01.5`
PCI bridges cannot cross the PCI segment boundaries, so the first "0000" will stay the same (doesn't need to be duplicated in the address).
### The value to a user, and who that user might be
Users will be less likely to have problems with PCI device renumbering.
opened 01:43PM - 30 Mar 23 UTC
closed 02:38PM - 03 Jul 25 UTC
C: Qubes GUI tools
ux
P: default
targets-4.3
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
###… The problem you're addressing (if any)
PCI numbering may change if devices are added or altered.(Cf #7792)
This means that device allocation to qubes may change.
### The solution you'd like
Absent a full solution at least provide warning when device allocation is made.
A warning could also be made in the docs.
### The value to a user, and who that user might be
Any user who may make hardware changes will have been warned of possible issues when they first make device allocations.
Whether they remember that warning is a separate issue.
Cf Forum discussion - https://forum.qubes-os.org/t/usability-issues-with-hardware-changes-on-system-qubes/17676
Ans those should answer your questions…
4 Likes
