From nobody Mon Feb 9 10:39:49 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1770193409345443.7715913768095; Wed, 4 Feb 2026 00:23:29 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id 6206341A4B; Wed, 4 Feb 2026 03:23:28 -0500 (EST) Received: from [172.19.199.6] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id 0544843FF8; Wed, 4 Feb 2026 03:15:33 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id 9A7803F282; Tue, 3 Feb 2026 17:12:21 -0500 (EST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 9D4CF41999 for ; Tue, 3 Feb 2026 17:12:20 -0500 (EST) Received: from [10.137.0.23] (unknown [82.64.227.213]) by smtp5-g21.free.fr (Postfix) with ESMTP id DC06D5FF95 for ; Tue, 3 Feb 2026 23:12:18 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 Message-ID: Date: Tue, 3 Feb 2026 23:12:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: devel@lists.libvirt.org From: Bertrand Leconte Subject: Failed to find parent device on Arrow Lake processor Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: quoted-printable X-MailFrom: bertrand@famille-leconte.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation Message-ID-Hash: NE62XCNHTWTFN4SFNTTSLI2W6BGGM64W X-Message-ID-Hash: NE62XCNHTWTFN4SFNTTSLI2W6BGGM64W X-Mailman-Approved-At: Wed, 04 Feb 2026 08:15:20 +0000 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-ZM-MESSAGEID: 1770193411117158500 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=20 is in the Arrow Lake family. The associated PCH is an Intel 800 Series=20 WM880. The particularity of this platform is that the PCH includes a=20 dedicated PCI Root Complex in addition to the CPU one. That means that I have devices connected to `0000:00` bus (addresses=20 like 0000:00:xx.x) and devices connected to `0000:80` bus (addresses=20 like 0000:80:xx.x). The consequence of that architecture is that there is no PCI Root Port=20 serving the `0000:80` bus. When I want to PCI passthrough my USB controller device `0000:80:14.0`,=20 the function `virPCIDeviceIsBehindSwitchLackingACS()` says that `Failed=20 to find parent device for 0000:80:14.0`. When I look into the source code, it looks like it enumerates all PCI=20 devices, searching for the Root Port managing the bus `0000:80`. As I=20 said before, it cannot find any as it's A Root Complex that manage the=20 `0000:80` bus and not a Root Port (a Root Complex it's not a PCI/PCIe=20 device). However, for any device connected to PCI bus `0000:00`, it=20 cannot find any PCI Root Port either but there is an exception in the=20 code for it. @Bloged (one of Qubes OS users) proposed in=20 https://forum.qubes-os.org/t/aistone-x6ar57ty-aka-tongfang-x6-16-intel-high= -end-performance/37944/2=20 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 @@=20 virPCIDeviceIsBehindSwitchLackingACS(virPCIDevice *dev) =C2=A0 =C2=A0 =C2=A0if (virPCIDeviceGetParent(dev, &parent) < 0) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return -1; =C2=A0 =C2=A0 =C2=A0if (!parent) { -=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* if we have no parent, and this is the root = bus, ACS doesn't come -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* into play since devices on the root bu= s can't P2P without going -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* through the root IOMMU. +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* i= f we have no parent, and this is a root-like=20 bus (0 or 0x80), +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* ACS doesn't come into play since devic= es on these buses=20 can't P2P +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* without going through the root IOMMU. +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* Arrow Lake (Intel Core Ultra 200 serie= s) uses bus 0x80 for=20 integrated +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* devices like USB controllers, with a c= omplex PCH topology=20 that confuses +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* parent device detection. Treat bus 0x8= 0 like bus 0 for ACS=20 purposes. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (dev->address.bus =3D=3D 0) { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 0; +=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else if (dev->address.bus =3D=3D 0x80) { +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VIR_DEBUG("%s %s: Arrow Lake bus= 0x80 device, treating as=20 root bus for ACS check", +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 dev->id, dev->name); +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0virReportError(VIR_ERR_INT= ERNAL_ERROR, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 _("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=20 indicate that this part of the code may not be necessary:=20 https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/QRI4= L5YFGBAV7NCTJ5OOJ7GBYGHQ7WZQ/#K5WRR6WTAUEPRQBWJVJSMX554DTYFTYH. My question: can someone that knows this part of the code have a look to=20 see what is the best way to correct it: either propose a patch to=20 `virPCIDeviceIsBehindSwitchLackingACS` that is more generic or to change=20 the rest of the code so it's no more used? (By the way, internationalization of error messages in=20 syslog/dmesg/journald does not look like a good idea. It is very hard to=20 understand if the message is given in French in this mailing list=E2=80=A6) Thanks very much for your help Bertrand