Failed to find parent device on Arrow Lake processor
Hello, I am using libvirt within Qubes OS (https://www.qubes-or.org). My laptop is a Lenovo P16 Gen 3 with an Intel Core Ultra 9 275HX, which is in the Arrow Lake family. The associated PCH is an Intel 800 Series WM880. The particularity of this platform is that the PCH includes a dedicated PCI Root Complex in addition to the CPU one. That means that I have devices connected to `0000:00` bus (addresses like 0000:00:xx.x) and devices connected to `0000:80` bus (addresses like 0000:80:xx.x). The consequence of that architecture is that there is no PCI Root Port serving the `0000:80` bus. When I want to PCI passthrough my USB controller device `0000:80:14.0`, the function `virPCIDeviceIsBehindSwitchLackingACS()` says that `Failed to find parent device for 0000:80:14.0`. When I look into the source code, it looks like it enumerates all PCI devices, searching for the Root Port managing the bus `0000:80`. As I said before, it cannot find any as it's A Root Complex that manage the `0000:80` bus and not a Root Port (a Root Complex it's not a PCI/PCIe device). However, for any device connected to PCI bus `0000:00`, it cannot find any PCI Root Port either but there is an exception in the code for it. @Bloged (one of Qubes OS users) proposed in https://forum.qubes-os.org/t/aistone-x6ar57ty-aka-tongfang-x6-16-intel-high-... to change the code to diff --git a/src/util/virpci.c b/src/util/virpci.c index 3816369..fbed8f5 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2555,12 +2555,20 @@ virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) if (virPCIDeviceGetParent(dev, &parent) < 0) return -1; if (!parent) { - /* if we have no parent, and this is the root bus, ACS doesn't come - * into play since devices on the root bus can't P2P without going - * through the root IOMMU. + /* if we have no parent, and this is a root-like bus (0 or 0x80), + * ACS doesn't come into play since devices on these buses can't P2P + * without going through the root IOMMU. + * + * Arrow Lake (Intel Core Ultra 200 series) uses bus 0x80 for integrated + * devices like USB controllers, with a complex PCH topology that confuses + * parent device detection. Treat bus 0x80 like bus 0 for ACS purposes. */ if (dev->address.bus == 0) { return 0; + } else if (dev->address.bus == 0x80) { + VIR_DEBUG("%s %s: Arrow Lake bus 0x80 device, treating as root bus for ACS check", + dev->id, dev->name); + return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to find parent device for %1$s"), -- This patch works, but it does not look very generic. In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4L.... My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used? (By the way, internationalization of error messages in syslog/dmesg/journald does not look like a good idea. It is very hard to understand if the message is given in French in this mailing list…) Thanks very much for your help Bertrand
On Tue, Feb 03, 2026 at 11:12:18PM +0100, Bertrand Leconte wrote:
Hello,
I am using libvirt within Qubes OS (https://www.qubes-or.org).
My laptop is a Lenovo P16 Gen 3 with an Intel Core Ultra 9 275HX, which is in the Arrow Lake family. The associated PCH is an Intel 800 Series WM880. The particularity of this platform is that the PCH includes a dedicated PCI Root Complex in addition to the CPU one. That means that I have devices connected to `0000:00` bus (addresses like 0000:00:xx.x) and devices connected to `0000:80` bus (addresses like 0000:80:xx.x). The consequence of that architecture is that there is no PCI Root Port serving the `0000:80` bus.
When I want to PCI passthrough my USB controller device `0000:80:14.0`, the function `virPCIDeviceIsBehindSwitchLackingACS()` says that `Failed to find parent device for 0000:80:14.0`.
When I look into the source code, it looks like it enumerates all PCI devices, searching for the Root Port managing the bus `0000:80`. As I said before, it cannot find any as it's A Root Complex that manage the `0000:80` bus and not a Root Port (a Root Complex it's not a PCI/PCIe device). However, for any device connected to PCI bus `0000:00`, it cannot find any PCI Root Port either but there is an exception in the code for it.
@Bloged (one of Qubes OS users) proposed in https://forum.qubes-os.org/t/aistone-x6ar57ty-aka-tongfang-x6-16-intel-high-... to change the code to diff --git a/src/util/virpci.c b/src/util/virpci.c index 3816369..fbed8f5 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2555,12 +2555,20 @@ virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) if (virPCIDeviceGetParent(dev, &parent) < 0) return -1; if (!parent) { - /* if we have no parent, and this is the root bus, ACS doesn't come - * into play since devices on the root bus can't P2P without going - * through the root IOMMU. + /* if we have no parent, and this is a root-like bus (0 or 0x80), + * ACS doesn't come into play since devices on these buses can't P2P + * without going through the root IOMMU. + * + * Arrow Lake (Intel Core Ultra 200 series) uses bus 0x80 for integrated + * devices like USB controllers, with a complex PCH topology that confuses + * parent device detection. Treat bus 0x80 like bus 0 for ACS purposes. */ if (dev->address.bus == 0) { return 0; + } else if (dev->address.bus == 0x80) { + VIR_DEBUG("%s %s: Arrow Lake bus 0x80 device, treating as root bus for ACS check", + dev->id, dev->name); + return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to find parent device for %1$s"), --
This patch works, but it does not look very generic.
Indeed, the correct way would be to look at /sys/devices/pciNNNN.NN to identity root complexes, but.....
In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4L....
My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used?
....That thread certainly suggests we have a large set of code that can be purged. Libvirt only needs to support the 2 most recent releases of each distro, and since the kerenl removed legacy device assignment 8 years ago I see no reason for us to keep this. This still begs the question of how you hit this code path to begin with, since Laine's message above suggests it ought to be impossible to hit already. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Le 04/02/2026 à 10:02, Daniel P. Berrangé a écrit :
On Tue, Feb 03, 2026 at 11:12:18PM +0100, Bertrand Leconte wrote:
Hello,
I am using libvirt within Qubes OS (https://www.qubes-or.org).
My laptop is a Lenovo P16 Gen 3 with an Intel Core Ultra 9 275HX, which is in the Arrow Lake family. The associated PCH is an Intel 800 Series WM880. The particularity of this platform is that the PCH includes a dedicated PCI Root Complex in addition to the CPU one. That means that I have devices connected to `0000:00` bus (addresses like 0000:00:xx.x) and devices connected to `0000:80` bus (addresses like 0000:80:xx.x). The consequence of that architecture is that there is no PCI Root Port serving the `0000:80` bus.
When I want to PCI passthrough my USB controller device `0000:80:14.0`, the function `virPCIDeviceIsBehindSwitchLackingACS()` says that `Failed to find parent device for 0000:80:14.0`.
When I look into the source code, it looks like it enumerates all PCI devices, searching for the Root Port managing the bus `0000:80`. As I said before, it cannot find any as it's A Root Complex that manage the `0000:80` bus and not a Root Port (a Root Complex it's not a PCI/PCIe device). However, for any device connected to PCI bus `0000:00`, it cannot find any PCI Root Port either but there is an exception in the code for it.
@Bloged (one of Qubes OS users) proposed in https://forum.qubes-os.org/t/aistone-x6ar57ty-aka-tongfang-x6-16-intel-high-... to change the code to diff --git a/src/util/virpci.c b/src/util/virpci.c index 3816369..fbed8f5 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2555,12 +2555,20 @@ virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) if (virPCIDeviceGetParent(dev, &parent) < 0) return -1; if (!parent) { - /* if we have no parent, and this is the root bus, ACS doesn't come - * into play since devices on the root bus can't P2P without going - * through the root IOMMU. + /* if we have no parent, and this is a root-like bus (0 or 0x80), + * ACS doesn't come into play since devices on these buses can't P2P + * without going through the root IOMMU. + * + * Arrow Lake (Intel Core Ultra 200 series) uses bus 0x80 for integrated + * devices like USB controllers, with a complex PCH topology that confuses + * parent device detection. Treat bus 0x80 like bus 0 for ACS purposes. */ if (dev->address.bus == 0) { return 0; + } else if (dev->address.bus == 0x80) { + VIR_DEBUG("%s %s: Arrow Lake bus 0x80 device, treating as root bus for ACS check", + dev->id, dev->name); + return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to find parent device for %1$s"), --
This patch works, but it does not look very generic. Indeed, the correct way would be to look at /sys/devices/pciNNNN.NN to identity root complexes, but.....
In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4L....
My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used? ....That thread certainly suggests we have a large set of code that can be purged. Libvirt only needs to support the 2 most recent releases of each distro, and since the kerenl removed legacy device assignment 8 years ago I see no reason for us to keep this.
This still begs the question of how you hit this code path to begin with, since Laine's message above suggests it ought to be impossible to hit already.
I asked the question under the issue I created on Qubes' github (https://github.com/QubesOS/qubes-issues/issues/10393). I hope someone there will be able to provide a hint to understand. I will also look at it, but I am just a Qubes user, so I am not sure to understand what it's done that way (and it will take a lot of time) Thanks, Bertrand
With regards, Daniel
I asked the question under the issue I created on Qubes' github (https://github.com/QubesOS/qubes-issues/issues/10393). I hope someone there will be able to provide a hint to understand. I will also look at it, but I am just a Qubes user, so I am not sure to understand what it's done that way (and it will take a lot of time) Thanks, Bertrand
On Wed, Feb 04, 2026 at 09:02:47AM +0000, Daniel P. Berrangé via Devel wrote:
On Tue, Feb 03, 2026 at 11:12:18PM +0100, Bertrand Leconte wrote:
Hello,
I am using libvirt within Qubes OS (https://www.qubes-or.org).
My laptop is a Lenovo P16 Gen 3 with an Intel Core Ultra 9 275HX, which is in the Arrow Lake family. The associated PCH is an Intel 800 Series WM880. The particularity of this platform is that the PCH includes a dedicated PCI Root Complex in addition to the CPU one.
The closest I have is a Lunar Lake device (226V), but this one has only a single root complex, so I can't verify this directly. Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ?
That means that I have devices connected to `0000:00` bus (addresses like 0000:00:xx.x) and devices connected to `0000:80` bus (addresses like 0000:80:xx.x). The consequence of that architecture is that there is no PCI Root Port serving the `0000:80` bus.
When I want to PCI passthrough my USB controller device `0000:80:14.0`, the function `virPCIDeviceIsBehindSwitchLackingACS()` says that `Failed to find parent device for 0000:80:14.0`.
When I look into the source code, it looks like it enumerates all PCI devices, searching for the Root Port managing the bus `0000:80`. As I said before, it cannot find any as it's A Root Complex that manage the `0000:80` bus and not a Root Port (a Root Complex it's not a PCI/PCIe device). However, for any device connected to PCI bus `0000:00`, it cannot find any PCI Root Port either but there is an exception in the code for it.
@Bloged (one of Qubes OS users) proposed in https://forum.qubes-os.org/t/aistone-x6ar57ty-aka-tongfang-x6-16-intel-high-... to change the code to diff --git a/src/util/virpci.c b/src/util/virpci.c index 3816369..fbed8f5 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2555,12 +2555,20 @@ virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) if (virPCIDeviceGetParent(dev, &parent) < 0) return -1; if (!parent) { - /* if we have no parent, and this is the root bus, ACS doesn't come - * into play since devices on the root bus can't P2P without going - * through the root IOMMU. + /* if we have no parent, and this is a root-like bus (0 or 0x80), + * ACS doesn't come into play since devices on these buses can't P2P + * without going through the root IOMMU. + * + * Arrow Lake (Intel Core Ultra 200 series) uses bus 0x80 for integrated + * devices like USB controllers, with a complex PCH topology that confuses + * parent device detection. Treat bus 0x80 like bus 0 for ACS purposes. */ if (dev->address.bus == 0) { return 0; + } else if (dev->address.bus == 0x80) { + VIR_DEBUG("%s %s: Arrow Lake bus 0x80 device, treating as root bus for ACS check", + dev->id, dev->name); + return 0; } else { virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to find parent device for %1$s"), --
This patch works, but it does not look very generic.
Indeed, the correct way would be to look at /sys/devices/pciNNNN.NN to identity root complexes, but.....
Interestingly, I do have a device with a root complex at 0x80, and also at 0xc0, and libvirt is happy about assigning devices behind them (specifically, c1:00.0, which is behind root complex at 0xc0). I guess virPCIDeviceGetParent() does find the parent in my case. That particular HW runs older libvirt version (still 8.9.0...), and I can't check right now how it behaves on the newer version. But looking at the diff since then, I don't see any relevant changes. Relevant part of `lspci -t`: +-[0000:80]-+-00.0 | +-00.2 | +-01.0 | +-02.0 | +-03.0 | +-03.1-[81]-- | +-03.2-[82]-- ... \-[0000:c0]-+-00.0 +-00.2 +-01.0 +-02.0 +-03.0 +-03.1-[c1]----00.0 +-03.2-[c2]----00.0 +-03.3-[c3]----00.0 +-03.4-[c4]----00.0
In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4L....
My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used?
....That thread certainly suggests we have a large set of code that can be purged. Libvirt only needs to support the 2 most recent releases of each distro, and since the kerenl removed legacy device assignment 8 years ago I see no reason for us to keep this.
IIUC that thread is talking about KVM only. Here we have Xen. I'm not sure what "legacy assignment" is in the KVM world, but I don't think there were any changes in this API on Xen side in the last decade or so. Theoretically, checks like this should be done by Xen (either libxl, or the hypervisor itself). But in practice, libvirt does it more comprehensively and provides better error messages (when it works). -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ?
I don't have any device at address 80:00.0. -+-[0000:00]-+-00.0 Intel Corporation Arrow Lake-HX 8p+16e cores Host Bridge | +-01.0-[04]----00.0 Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1] | +-02.0 Intel Corporation Arrow Lake-S [Intel Graphics] | +-04.0 Intel Corporation Device ad03 | +-06.0-[01]--+-00.0 NVIDIA Corporation GB207GLM [RTX PRO 1000 Blackwell Generation Laptop GPU] | | \-00.1 NVIDIA Corporation GB207 High Definition Audio Controller | +-07.0-[20-49]-- | +-08.0 Intel Corporation Arrow Lake-HX Gauss Newton Algorithm (GNA) | +-0a.0 Intel Corporation Arrow Lake-HX Crash Log & Telemetry | +-0b.0 Intel Corporation Arrow Lake NPU | +-0d.0 Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller | +-0d.2 Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #0 | +-14.0 Intel Corporation Arrow Lake-HX Shared SRAM (SOC-S) | +-1f.0 Intel Corporation Arrow Lake-HX Direct eSPI Controller | \-1f.5 Intel Corporation Arrow Lake-HX SPI (flash) Controller \-[0000:80]-+-14.0 Intel Corporation 800 Series PCH USB 3.1 xHCI HC +-14.5 Intel Corporation Device 7f2f +-15.0 Intel Corporation 800 Series PCH I2C Controller #0 +-15.3 Intel Corporation 800 Series PCH I2C Controller #3 +-16.0 Intel Corporation 800 Series PCH HECI #1 +-19.0 Intel Corporation 800 Series PCH I2C Controller #4 +-19.1 Intel Corporation 800 Series PCH I2C Controller #5 +-1b.0-[83]-- +-1b.4-[88-d8]----00.0-[89-8d]--+-00.0-[8a]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G NHI [Barlow Ridge Host 80G 2023] | +-01.0-[8b]-- | +-02.0-[8c]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G USB Controller [Barlow Ridge Host 80G 2023] | \-03.0-[8d]-- +-1c.0-[81]-- +-1c.6-[86]----00.0 Intel Corporation Ethernet Controller I226-V +-1d.0-[82]-- +-1d.4-[85]----00.0 O2 Micro, Inc. Device 9860 +-1d.6-[84]----00.0 Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 +-1f.0 Intel Corporation Device 7f12 +-1f.3 Intel Corporation 800 Series ACE (Audio Context Engine) +-1f.4 Intel Corporation 800 Series PCH SMBus Controller \-1f.5 Intel Corporation 800 Series PCH SPI (flash) Controller -- Bertrand
On Thu, Feb 05, 2026 at 10:38:27PM -0000, bertrandlec--- via Devel wrote:
Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ?
I don't have any device at address 80:00.0.
Oh, that's why it fails... This feels like a firmware (if not hardware) issue, I think root complex should be visible normally... But maybe somebody more familiar with PCIe spec can help?
-+-[0000:00]-+-00.0 Intel Corporation Arrow Lake-HX 8p+16e cores Host Bridge | +-01.0-[04]----00.0 Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1] | +-02.0 Intel Corporation Arrow Lake-S [Intel Graphics] | +-04.0 Intel Corporation Device ad03 | +-06.0-[01]--+-00.0 NVIDIA Corporation GB207GLM [RTX PRO 1000 Blackwell Generation Laptop GPU] | | \-00.1 NVIDIA Corporation GB207 High Definition Audio Controller | +-07.0-[20-49]-- | +-08.0 Intel Corporation Arrow Lake-HX Gauss Newton Algorithm (GNA) | +-0a.0 Intel Corporation Arrow Lake-HX Crash Log & Telemetry | +-0b.0 Intel Corporation Arrow Lake NPU | +-0d.0 Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller | +-0d.2 Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #0 | +-14.0 Intel Corporation Arrow Lake-HX Shared SRAM (SOC-S) | +-1f.0 Intel Corporation Arrow Lake-HX Direct eSPI Controller | \-1f.5 Intel Corporation Arrow Lake-HX SPI (flash) Controller \-[0000:80]-+-14.0 Intel Corporation 800 Series PCH USB 3.1 xHCI HC +-14.5 Intel Corporation Device 7f2f +-15.0 Intel Corporation 800 Series PCH I2C Controller #0 +-15.3 Intel Corporation 800 Series PCH I2C Controller #3 +-16.0 Intel Corporation 800 Series PCH HECI #1 +-19.0 Intel Corporation 800 Series PCH I2C Controller #4 +-19.1 Intel Corporation 800 Series PCH I2C Controller #5 +-1b.0-[83]-- +-1b.4-[88-d8]----00.0-[89-8d]--+-00.0-[8a]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G NHI [Barlow Ridge Host 80G 2023] | +-01.0-[8b]-- | +-02.0-[8c]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G USB Controller [Barlow Ridge Host 80G 2023] | \-03.0-[8d]-- +-1c.0-[81]-- +-1c.6-[86]----00.0 Intel Corporation Ethernet Controller I226-V +-1d.0-[82]-- +-1d.4-[85]----00.0 O2 Micro, Inc. Device 9860 +-1d.6-[84]----00.0 Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 +-1f.0 Intel Corporation Device 7f12 +-1f.3 Intel Corporation 800 Series ACE (Audio Context Engine) +-1f.4 Intel Corporation 800 Series PCH SMBus Controller \-1f.5 Intel Corporation 800 Series PCH SPI (flash) Controller
-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
On Fri, Feb 06, 2026 at 02:17:40PM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Feb 05, 2026 at 10:38:27PM -0000, bertrandlec--- via Devel wrote:
Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ?
I don't have any device at address 80:00.0.
Oh, that's why it fails...
This feels like a firmware (if not hardware) issue, I think root complex should be visible normally... But maybe somebody more familiar with PCIe spec can help?
Yeah, checking if there is any firmware update available would be a good idea, as to me it is a bit odd to see the separate hierarchy without a host bridge at 0000:80:00.0. Admittedly I'm not a PCIE expert though
-+-[0000:00]-+-00.0 Intel Corporation Arrow Lake-HX 8p+16e cores Host Bridge | +-01.0-[04]----00.0 Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1] | +-02.0 Intel Corporation Arrow Lake-S [Intel Graphics] | +-04.0 Intel Corporation Device ad03 | +-06.0-[01]--+-00.0 NVIDIA Corporation GB207GLM [RTX PRO 1000 Blackwell Generation Laptop GPU] | | \-00.1 NVIDIA Corporation GB207 High Definition Audio Controller | +-07.0-[20-49]-- | +-08.0 Intel Corporation Arrow Lake-HX Gauss Newton Algorithm (GNA) | +-0a.0 Intel Corporation Arrow Lake-HX Crash Log & Telemetry | +-0b.0 Intel Corporation Arrow Lake NPU | +-0d.0 Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller | +-0d.2 Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #0 | +-14.0 Intel Corporation Arrow Lake-HX Shared SRAM (SOC-S) | +-1f.0 Intel Corporation Arrow Lake-HX Direct eSPI Controller | \-1f.5 Intel Corporation Arrow Lake-HX SPI (flash) Controller \-[0000:80]-+-14.0 Intel Corporation 800 Series PCH USB 3.1 xHCI HC +-14.5 Intel Corporation Device 7f2f +-15.0 Intel Corporation 800 Series PCH I2C Controller #0 +-15.3 Intel Corporation 800 Series PCH I2C Controller #3 +-16.0 Intel Corporation 800 Series PCH HECI #1 +-19.0 Intel Corporation 800 Series PCH I2C Controller #4 +-19.1 Intel Corporation 800 Series PCH I2C Controller #5 +-1b.0-[83]-- +-1b.4-[88-d8]----00.0-[89-8d]--+-00.0-[8a]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G NHI [Barlow Ridge Host 80G 2023] | +-01.0-[8b]-- | +-02.0-[8c]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G USB Controller [Barlow Ridge Host 80G 2023] | \-03.0-[8d]-- +-1c.0-[81]-- +-1c.6-[86]----00.0 Intel Corporation Ethernet Controller I226-V +-1d.0-[82]-- +-1d.4-[85]----00.0 O2 Micro, Inc. Device 9860 +-1d.6-[84]----00.0 Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 +-1f.0 Intel Corporation Device 7f12 +-1f.3 Intel Corporation 800 Series ACE (Audio Context Engine) +-1f.4 Intel Corporation 800 Series PCH SMBus Controller \-1f.5 Intel Corporation 800 Series PCH SPI (flash) Controller
-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel P. Berrangé wrote:
On Fri, Feb 06, 2026 at 02:17:40PM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Feb 05, 2026 at 10:38:27PM -0000, bertrandlec--- via Devel wrote:
Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ? I don't have any device at address 80:00.0. Oh, that's why it fails... This feels like a firmware (if not hardware) issue, I think root complex should be visible normally... But maybe somebody more familiar with PCIe spec can help? Yeah, checking if there is any firmware update available would be a good idea, as to me it is a bit odd to see the separate hierarchy without a host bridge at 0000:80:00.0. Admittedly I'm not a PCIE expert though
I am using the lastest version of the Laptop firmware. The last version was published yesterday and it does not change that behaviour. I redid my test on that version. From my reading on PCI/PCIe (but I am definitively not an expert), a PCI Host Bridge or a PCIe Root Complex does not necessarely need to be addressable on the PCI bus, specially on a PCH when it is connected to the CPU SoC by a proprietary bus (Intel DMI Direct Media Interface in my case). On my laptop, the bus 0000:80 is recognized by Linux, as shown in the "lspci -t" output. My understanding is that it's a configuration that works and all devices are accessible. The second PCIe Root Complex is correctly described in ACPI tables enough to be accepted by Linux Kernel. Can I do something to help? Thanks Bertrand
On Thu, Feb 05, 2026 at 10:38:27PM -0000, bertrandlec--- via Devel wrote:
Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ?
Having read this https://www.techpowerup.com/review/intel-core-ultra-arrow-lake-preview/5.htm... I think I somewhat understand what your machine is showing here. The CPU itself has integrated PCI host bridge, and then there's a further hostbridge provided by the 800 series chipset
I don't have any device at address 80:00.0.
-+-[0000:00]-+-00.0 Intel Corporation Arrow Lake-HX 8p+16e cores Host Bridge | +-01.0-[04]----00.0 Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1] | +-02.0 Intel Corporation Arrow Lake-S [Intel Graphics] | +-04.0 Intel Corporation Device ad03 | +-06.0-[01]--+-00.0 NVIDIA Corporation GB207GLM [RTX PRO 1000 Blackwell Generation Laptop GPU] | | \-00.1 NVIDIA Corporation GB207 High Definition Audio Controller | +-07.0-[20-49]-- | +-08.0 Intel Corporation Arrow Lake-HX Gauss Newton Algorithm (GNA) | +-0a.0 Intel Corporation Arrow Lake-HX Crash Log & Telemetry | +-0b.0 Intel Corporation Arrow Lake NPU | +-0d.0 Intel Corporation Meteor Lake-P Thunderbolt 4 USB Controller | +-0d.2 Intel Corporation Meteor Lake-P Thunderbolt 4 NHI #0 | +-14.0 Intel Corporation Arrow Lake-HX Shared SRAM (SOC-S) | +-1f.0 Intel Corporation Arrow Lake-HX Direct eSPI Controller | \-1f.5 Intel Corporation Arrow Lake-HX SPI (flash) Controller
So this ^^^^^ is all on the CPU integrated host bridge....and...
\-[0000:80]-+-14.0 Intel Corporation 800 Series PCH USB 3.1 xHCI HC +-14.5 Intel Corporation Device 7f2f +-15.0 Intel Corporation 800 Series PCH I2C Controller #0 +-15.3 Intel Corporation 800 Series PCH I2C Controller #3 +-16.0 Intel Corporation 800 Series PCH HECI #1 +-19.0 Intel Corporation 800 Series PCH I2C Controller #4 +-19.1 Intel Corporation 800 Series PCH I2C Controller #5 +-1b.0-[83]-- +-1b.4-[88-d8]----00.0-[89-8d]--+-00.0-[8a]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G NHI [Barlow Ridge Host 80G 2023] | +-01.0-[8b]-- | +-02.0-[8c]----00.0 Intel Corporation JHL9580 Thunderbolt 5 80/120G USB Controller [Barlow Ridge Host 80G 2023] | \-03.0-[8d]-- +-1c.0-[81]-- +-1c.6-[86]----00.0 Intel Corporation Ethernet Controller I226-V +-1d.0-[82]-- +-1d.4-[85]----00.0 O2 Micro, Inc. Device 9860 +-1d.6-[84]----00.0 Intel Corporation Wi-Fi 7(802.11be) AX1775*/AX1790*/BE20*/BE401/BE1750* 2x2 +-1f.0 Intel Corporation Device 7f12 +-1f.3 Intel Corporation 800 Series ACE (Audio Context Engine) +-1f.4 Intel Corporation 800 Series PCH SMBus Controller \-1f.5 Intel Corporation 800 Series PCH SPI (flash) Controller
.....this ^^^ is all on the 800 series chipset host bridge. In sysfs on your machine do you see multiple dir entries at /sys/devices/pciNNNN.NN ??? If so, that's how we can identify the root complexes, regardless of the unexpectedly missing host bridge at 0000:80:00.0 With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel P. Berrangé wrote:
On Thu, Feb 05, 2026 at 10:38:27PM -0000, bertrandlec--- via Devel wrote:
Bertrand, can you share `lspci -t` output, and also `lspci -vvs 80:00.0` ? Having read this
https://www.techpowerup.com/review/intel-core-ultra-arrow-lake-preview/5.htm...
I think I somewhat understand what your machine is showing here.
Yes, my PCH is a Intel 800 Series WM880.
The CPU itself has integrated PCI host bridge, and then there's a further hostbridge provided by the 800 series chipset
In sysfs on your machine do you see multiple dir entries at
/sys/devices/pciNNNN.NN
??? If so, that's how we can identify the root complexes, regardless of the unexpectedly missing host bridge at 0000:80:00.0
Yes I have /sys/devices/pci0000:00 and /sys/devices/pci0000:80. Bertrand
On Thu, Feb 05, 2026 at 11:18:10PM +0100, Marek Marczykowski-Górecki wrote:
On Wed, Feb 04, 2026 at 09:02:47AM +0000, Daniel P. Berrangé via Devel wrote:
In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4L....
My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used?
....That thread certainly suggests we have a large set of code that can be purged. Libvirt only needs to support the 2 most recent releases of each distro, and since the kerenl removed legacy device assignment 8 years ago I see no reason for us to keep this.
IIUC that thread is talking about KVM only. Here we have Xen. I'm not sure what "legacy assignment" is in the KVM world, but I don't think there were any changes in this API on Xen side in the last decade or so.
Theoretically, checks like this should be done by Xen (either libxl, or the hypervisor itself). But in practice, libvirt does it more comprehensively and provides better error messages (when it works).
Yep, I completely overlooked that this was using Xen, and Xen does not support VFIO like KVM does. So we do indeed need to retain this logic, and fix any bugs. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Daniel P. Berrangé wrote:
Yep, I completely overlooked that this was using Xen, and Xen does not support VFIO like KVM does. So we do indeed need to retain this logic, and fix any bugs.
Maybe you can add a comment in the source file to remember not to remove that code :-) ! Bertrand
Hey guys, joining the thread as I'm having the same issue Bertrand is having and would like to help if possible. Even though virtualization libs isn't my specialty, since it affects me i'm extremely motivated! Are we saying that the issue should be fixed in Xen and not libvirt? As i understand it; Isn't the problem in libvirt here: ``` if (dev->address.bus == 0) { ``` ? Expects single bus device : `/sys/devices/pci0000:0` ? Doesn't consider a multiple bus scenario like in Arrow Lake? (0000:00 & 0000:80) Could libvirt lookup (several) available `/sys/devices/pciXXXX:YY` in a multi bus scenario? Best! Bruno
On 2/6/26 8:33 AM, Daniel P. Berrangé wrote:
On Thu, Feb 05, 2026 at 11:18:10PM +0100, Marek Marczykowski-Górecki wrote:
On Wed, Feb 04, 2026 at 09:02:47AM +0000, Daniel P. Berrangé via Devel wrote:
In addition to that, a thread in 2017 (this mailing list) seems to indicate that this part of the code may not be necessary: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4L....
My question: can someone that knows this part of the code have a look to see what is the best way to correct it: either propose a patch to `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change the rest of the code so it's no more used?
....That thread certainly suggests we have a large set of code that can be purged. Libvirt only needs to support the 2 most recent releases of each distro, and since the kerenl removed legacy device assignment 8 years ago I see no reason for us to keep this.
IIUC that thread is talking about KVM only.
Yep. Since all of my usage of libvirt is with the QEMU/KVM driver, my posts tend to speak in a "KVM-centric" manner (as if QEMU/KVM is the center of the libvirt universe and the rest doesn't exist :-)). But definitely what I was talking about was that the QEMU/KVM driver only uses VFIO now. I do think that somebody (could have been me, or could have been someone else, I have no memory) already went through and cleaned out the KVM-specific non-VFIO code several years ago (sometime after my message that you referenced).
Here we have Xen. I'm not sure what "legacy assignment" is in the KVM world, but I don't think there were any changes in this API on Xen side in the last decade or so.
Theoretically, checks like this should be done by Xen (either libxl, or the hypervisor itself). But in practice, libvirt does it more comprehensively and provides better error messages (when it works).
Yep, I completely overlooked that this was using Xen, and Xen does not support VFIO like KVM does. So we do indeed need to retain this logic, and fix any bugs.
I took a look through that code and saw that it's using a very inefficient method of traversing the PCI topology to visit all the parents of the device being assigned and have an idea for simplifying it that I want to try out (unless someone else beats me to it) - basically instead of iterating through every singe PCI device each time we look for the parent of the current device, we can just resolve the symlink for the device directory, e.g. /sys/bus/pci/devices/0000:08:00.3 which will give us something like: /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3 (an example from one of my machines. Sorry for any line breaks - stupid email client :-/) Once you have that path, you just break it down into the individual components, and that is the entire tree of "ancestors" for the endpoint device that need to be checked for ACS (and when you get to the component that is "pci0000:XX", that means you're at the root complex and so you're done. If my ADHD brain hasn't forgotten it by the time I wake up tomorrow, I'll try refactoring the code to do this (and then artificially re-enable the ACS check for VFIO so I can actually test it :-).
On 2/12/26 13:49, Laine Stump wrote:
I took a look through that code and saw that it's using a very inefficient method of traversing the PCI topology to visit all the parents of the device being assigned and have an idea for simplifying it that I want to try out (unless someone else beats me to it) - basically instead of iterating through every singe PCI device each time we look for the parent of the current device, we can just resolve the symlink for the device directory, e.g.
/sys/bus/pci/devices/0000:08:00.3 which will give us something like:
/sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.3
(an example from one of my machines. Sorry for any line breaks - stupid email client :-/)
Once you have that path, you just break it down into the individual components, and that is the entire tree of "ancestors" for the endpoint device that need to be checked for ACS (and when you get to the component that is "pci0000:XX", that means you're at the root complex and so you're done.
This looks very good yes, and probably way faster than the initial design. In addition to the lines changed in the proposed initial patch, you can find around line 1146 of virpci.c a test that induce a specific behaviour if the device is connected to the root complex. So if you can look at that part too, it would be marvelous!
If my ADHD brain hasn't forgotten it by the time I wake up tomorrow, I'll try refactoring the code to do this (and then artificially re-enable the ACS check for VFIO so I can actually test it :-).
I will be more than happy to help you to test. Qubes R4.3.0 is using libvirt version 10.5.2 but I assume virpci.c source file had not that much changed since then. Bertrand
Decided to take a stab at it: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/RDF5X... Best!
Laine Stump wrote:
If my ADHD brain hasn't forgotten it by the time I wake up tomorrow, I'll try refactoring the code to do this (and then artificially re-enable the ACS check for VFIO so I can actually test it :-).
On this subject, ehanoc@protonmail.com proposed a patch to solve this issue (https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/RDF5X...). What are the following steps for this patch to be validated and integrated into the code base? Thanks, Bertrand
participants (6)
-
Bertrand Leconte -
bertrandlec＠free.fr -
Daniel P. Berrangé -
ehanoc＠protonmail.com -
Laine Stump -
Marek Marczykowski-Górecki