Booting r4.3-rc4 will result in a kernel panic add the following intel_pmc_core.disable=1 initcall_blacklist=intel_pmc_ssram_telemetry_driver_init module_blacklist=intel_pmc_ssram_telemetry to the kernel line in GRUB.
For now both USB and WiFi (AX211) are not working.
Got those two working in a hacky way… created the following patch in qubes-builderv2.
From 7e6a40a78bd4048ffe4d6be05c9df69e6d6c8b19 Mon Sep 17 00:00:00 2001
From: Qubes Builder <builder@qubes-os.org>
Date: Tue, 16 Dec 2025 10:40:21 +0100
Subject: [PATCH] virpci: Treat Arrow Lake bus 0x80 as root bus for ACS checks
Arrow Lake (Intel Core Ultra 200 series) uses bus 0x80 for integrated
devices like USB controllers. The complex PCH topology confuses parent
device detection, causing 'Failed to find parent device' errors.
Treat bus 0x80 like bus 0 for ACS checking purposes.
Fixes: https://github.com/QubesOS/qubes-issues/issues/10393
---
src/util/virpci.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
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"),
--
2.51.1
Then added it in libvirt.spec.in and build this package. This way 0x80 and 0 are both considered root.
Transfered those packages to dom0 and installed the patched version over the ones that were already installed (check with rpm -qa | grep libvirt).
Reboot and now I have both my wifi and USB working (with strict reset).
It was your post that pointed me in the right direction… It should get into Qubes, but probably in a less hacky way; now it is hardcoded to the 0x80 that works for my (and your machine) but probably fails on some other machine.
As an alternative, would it have worked if the ACS override kernel patch was used with just the id of the offending bridge?
Something like pcie_acs_override=00:80.00 or so?
(but it would still require running a patched kernel)
Or perhaps that’s just for KVM?
Also, isn’t the ACS check in Xen/Kernel? Since the acs_override is a kernel patch.
And one more thing, are we sure it’s okay for this Bridge not to have ACS? I mean its child bridge does have it. We don’t passthrough bridges so technically speaking seems secure.
I think for the security part I would have to defer to someone more experienced in this field to respond. Currently as is it fits my threat model.
The problem, I see, with both this solution in libvirt and the one you propose in the kernel with ACS patch is that it requires the address to be hardcoded. I think that eliminates the viability of this patch for mainstream right now.
It seems all of Arrow Lake has it at 80. I will look into extending your patch to perhaps use the bus full ID. That should be unique instead of the 80 and work always.
Thank you very much for this proposal @Bloged. I made an additional reply in the Qubes Issue I opened at first, to continue the discussion on your post there.