- Devel - libvirt List Archives

[PATCH 0/5] hyperv: Implement basic snapshot query APIs
by Jonathon Jongsma 13 Mar '26

13 Mar '26

This is the first patch series adding snapshot support for the hyperv driver. It only implements the basic functions for querying information about snapshots and doesn't handle creating or deleting snapshots yet. Jonathon Jongsma (5): hyperv: Implement domainSnapshotLookupByName() hyperv: implement virDomainListAllSnapshots()/virDomainSnapshotNum() hyperv: implement virDomainSnapshotGetXMLDesc() hyperv: Implement virDomainSnapshotCurrent()/virDomainHasCurrentSnapshot() hyperv: Implement virDomainSnapshotGetParent() src/hyperv/hyperv_driver.c | 276 +++++++++++++++++++++++++++++++++++++ src/hyperv/hyperv_wmi.c | 20 +++ src/hyperv/hyperv_wmi.h | 7 + 3 files changed, 303 insertions(+) -- 2.53.0

2 7

virsh feature request: cold restart and/or synchronous shutdown option
by roy-orbitson＠devo.net.au 13 Mar '26

13 Mar '26

When libvirt components get updated on a hypervisor, VMs continue running with obsolete files. Programs like "needrestart" alert one to this condition with messages like: VM guests are running outdated hypervisor (qemu) binaries on this host: 'bazquux' with pid 1234 Normal restarting of a VM (from within or with `virsh reboot ...`) does not resolve it because it's 'warm'; VMs must be completely shut down then started again to utilise the updates. Afaik, to do so reliably, in a way that minimises downtime, requires scripts like this: (d=bazquux; virsh shutdown --domain "$d" && until LC_ALL=C LANG=C virsh domstate --domain "$d" | grep -Fi 'shut off' &> /dev/null; do echo ...; sleep 1; done && virsh start --domain "$d") Adding a timeout complicates that further. Options for this logic to be performed by virsh would be beneficial, as a single operation: virsh reboot --domain bazquux --cold And by allowing poweroff to wait: (d=bazquux; virsh shutdown --domain "$d" --synchronous && virsh start --domain "$d") The latter would also assist with scripting changes to a VM that can only be performed whilst it is not running (shutdown -> alter -> start). Ideally, these would accept `--timeout n` so that if the shutdown portion was not completed quickly enough, they would fail and exit with a non-zero status, and the former would not start the VM again. I'm not sure of a good way to handle this where `on_poweroff` is set to something that doesn't result in the machine being shut off.

5 8

[PATCH v1 0/1] rpc: fix virNetClient->error leak on teardown
by Leander Kohler 12 Mar '26

12 Mar '26

Hi all, this is my first contribution to libvirt upstream. I am with Cyberus Technology, where I work on cloud-hypervisor and its integration with OpenStack and libvirt. The following fixes a leak in virNetClient teardown. virNetClientMarkClose() may save the current error in client->error (via virSaveLastError()). We usually free that in virNetClientCloseLocked(), but we can also end up disposing the client without going through that cleanup. One path where this happens is: virConnectDispose() -> remoteConnectClose() -> doRemoteClose() -> virNetClientClose(priv->client) -> g_clear_pointer(&priv->client, virObjectUnref) In that case, client->error can stay allocated until finalization, and ASan reports a leak. Fix is to also clear client->error in virNetClientDispose() as a final fallback. I included an ASan trace below. Thanks, Leander --- Line numbers in this trace come from our downstream libvirt fork and may differ from upstream, but the call path/function names are the same. [ 276.247727] virtchd[4030]: ==4030==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x7fcd6009e110 in calloc (libasan.so.8+0xfc110) #1 0x7fcd5dcb95bd in g_malloc0 (libglib-2.0.so.0+0x6d5bd) #2 0x7fcd5eb15f31 in virSaveLastError ../src/util/virerror.c:413 #3 0x7fcd5ee6c76c in virNetClientMarkClose ../src/rpc/virnetclient.c:776 #4 0x7fcd5ee6f782 in virNetClientCloseInternal ../src/rpc/virnetclient.c:837 #5 0x7fcd5f0150e4 in doRemoteClose ../src/remote/remote_driver.c:1414 #6 0x7fcd5f0150e4 in remoteConnectClose ../src/remote/remote_driver.c:1442 #7 0x7fcd5f1a90ef in virConnectDispose ../src/datatypes.c:174 #8 0x7fcd5ea58ebb in vir_object_finalize ../src/util/virobject.c:323 #9 0x7fcd5dc05c52 in g_object_unref (libgobject-2.0.so.0+0x1ec52) #10 0x7fcd5ea59fc7 in virObjectUnref ../src/util/virobject.c:377 #11 0x7fcd5ea59fc7 in virObjectUnref ../src/util/virobject.c:370 #12 0x7fcd5ef3a92f in glib_autoptr_clear_virConnect ../src/datatypes.h:548 #13 0x7fcd5ef3a92f in glib_autoptr_cleanup_virConnect ../src/datatypes.h:548 #14 0x7fcd5ef3a92f in virDomainInterfaceDeleteDevice ../src/hypervisor/domain_interface.c:419 #15 0x7fcd594a0cd3 in virCHProcessStopOrKill ../src/ch/ch_process.c:1308 #16 0x7fcd594a8bfa in virCHProcessStop ../src/ch/ch_process.c:1363 #17 0x7fcd5945d8c7 in chDomainDestroyFlags ../src/ch/ch_driver.c:959 #18 0x7fcd5f0f69c0 in virDomainDestroy ../src/libvirt-domain.c:514 #19 0x55c25777376a in remoteDispatchDomainDestroy src/remote/remote_daemon_dispatch_stubs.h:5485 #20 0x55c25777376a in remoteDispatchDomainDestroyHelper src/remote/remote_daemon_dispatch_stubs.h:5464 #21 0x7fcd5ee7c42c in virNetServerProgramDispatchCall ../src/rpc/virnetserverprogram.c:423 #22 0x7fcd5ee7c42c in virNetServerProgramDispatch ../src/rpc/virnetserverprogram.c:299 #23 0x7fcd5ee97c6c in virNetServerProcessMsg ../src/rpc/virnetserver.c:135 #24 0x7fcd5ee98b43 in virNetServerHandleJob ../src/rpc/virnetserver.c:155 #25 0x7fcd5eadbce2 in virThreadPoolWorker ../src/util/virthreadpool.c:164 #26 0x7fcd5eada3c9 in virThreadHelper ../src/util/virthread.c:256 #27 0x7fcd60004cd5 in asan_thread_start(void*) (libasan.so.8+0x62cd5) #28 0x7fcd5d200979 in start_thread (libc.so.6+0x9a979) #29 0x7fcd5d288d2b in __GI___clone3 (libc.so.6+0x122d2b) Objects leaked above: 0x507000064400 (80 bytes) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 1 allocation(s). Leander Kohler (1): rpc: free saved close error in virNetClientDispose src/rpc/virnetclient.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.51.2

2 2

[PATCH] util: implement virHostCPUGetOnlineBitmap() for FreeBSD
by Roman Bogorodskiy 12 Mar '26

12 Mar '26

Implement virHostCPUGetOnlineBitmap() for FreeBSD. As FreeBSD supports neither plugging nor taking CPUs offline, all CPUs are always online. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/util/virhostcpu.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 7cecb4b2c8..8688b6ec67 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1120,6 +1120,19 @@ virHostCPUGetOnlineBitmap(void) virFileReadValueBitmap(&ret, "%s/cpu/online", SYSFS_SYSTEM_PATH); + return ret; +#elif defined(__FreeBSD__) + virBitmap *ret = NULL; + int ncpus = virHostCPUGetCountAppleFreeBSD(); + + if (ncpus == -1) + return ret; + + /* FreeBSD does not support CPU hotplug, so it is safe to assume + * that all available CPUs are online */ + ret = virBitmapNew(ncpus); + virBitmapSetAll(ret); + return ret; #else virReportError(VIR_ERR_NO_SUPPORT, "%s", -- 2.52.0

2 1

[RFC PATCH v2 0/2] qemu: Support vCMDQ
by Nathan Chen 11 Mar '26

11 Mar '26

Hi, This is a follow up to the previous RFC patchset [0] for supporting Tegra241 vCMDQ. This patchset is tested with Shameer's v3 qemu series [1] for vCMDQ support. The accelerated SMMUv3 series for qemu and Libvirt [2] are pre-requisites for vCMDQ support, as accelerated SMMUv3 must be enabled alongside vCMDQ. A new 'cmdqv' <iommu> driver attribute is introduced to toggle enabling vCMDQ support. For instance, specifying hostdevs associated with multiple accelerated SMMUs + CMDQV enabled, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host: <devices> ... <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='248'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> ... <controller type='pci' index='21' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='21' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='22' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='22' port='0xa8'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver pciBus='1' accel='on' ats='on' ril='on' ssidSize='20' oas='44' cmdqv='on'/> </iommu> <iommu model='smmuv3'> <driver pciBus='2' accel='on' ats='on' ril='on' ssidSize='20' oas='44' cmdqv='on'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pxb-pcie","bus_nr":248,"id":"pci.2","bus":"pcie.0","addr":"0x2"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":21,"id":"pci.21","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"pcie-root-port","port":168,"chassis":22,"id":"pci.22","bus":"pci.2","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"iommu0","accel":true,"ats":true,"cmdqv":"on","ril":true,"pasid":true,"oas":44}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":true,"cmdqv":"on","ril":true,"pasid":true,"oas":44}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/cmdqv-03-26/ Thanks, Nathan Changes from v1: - Remove 'identifier' attribute for SMMUv3 - Change QEMU command line property from 'tegra241-cmdqv' to 'cmdqv' - Support QEMU OnOffAuto CMDQV property instead of expecting a bool [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NHVK… [1] https://lore.kernel.org/all/20260226105056.897-1-skolothumtho@nvidia.com/ [2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/5GG7… Nathan Chen (2): qemu: Support NVIDIA Tegra241 CMDQV for SMMUv3 tests: qemuxmlconfdata: provide cmdqv sample XML and CLI args docs/formatdomain.rst | 6 ++ src/conf/domain_conf.c | 15 ++++ src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 5 +- src/conf/schemas/domaincommon.rng | 5 ++ src/qemu/qemu_command.c | 1 + ...u-smmuv3-pci-bus-cmdqv.aarch64-latest.args | 45 +++++++++++ ...mu-smmuv3-pci-bus-cmdqv.aarch64-latest.xml | 76 +++++++++++++++++++ .../iommu-smmuv3-pci-bus-cmdqv.xml | 66 ++++++++++++++++ tests/qemuxmlconftest.c | 1 + 10 files changed, 220 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-cmdqv.xml -- 2.43.0

1 2

[PATCH v7 0/2] qemu: Support accelerated vSMMUs
by Nathan Chen 11 Mar '26

11 Mar '26

Hi, This is a follow up to the sixth RFC patchset [0] for supporting multiple accelerated vSMMU instances. Support for user-creatable accelerated SMMUv3 in QEMU has been applied to target-arm.next [1]. For instance, specifying hostdevs associated with multiple accelerated SMMUs, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host: <devices> ... <controller type='pci' index='1' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='252'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </controller> <controller type='pci' index='2' model='pcie-expander-bus'> <model name='pxb-pcie'/> <target busNr='248'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> ... <controller type='pci' index='21' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='21' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> <controller type='pci' index='22' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='22' port='0xa8'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <vpasidCapOffset>0xff8</vpasidCapOffset> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <vpasidCapOffset>0xff8</vpasidCapOffset> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver parentIdx='1' accel='on' ats='on' ril='off' ssidSize='20' oas='44'/> </iommu> <iommu model='smmuv3'> <driver parentIdx='2' accel='on' ats='on' ril='off' ssidSize='20' oas='44'/> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -device '{"driver":"pxb-pcie","bus_nr":252,"id":"pci.1","bus":"pcie.0","addr":"0x1"}' \ -device '{"driver":"pxb-pcie","bus_nr":248,"id":"pci.2","bus":"pcie.0","addr":"0x2"}' \ -device '{"driver":"pcie-root-port","port":0,"chassis":21,"id":"pci.21","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"pcie-root-port","port":168,"chassis":22,"id":"pci.22","bus":"pci.2","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"iommu0","accel":true,"ats":true,"ril":false,"ssidsize":20,"oas":44}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":true,"ril":false,"ssidsize":20,"oas":44}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","x-vpasid-cap-offset":4088,"bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","x-vpasid-cap-offset":4088,"bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3-accel-01-26-v7/ Thanks, Nathan Changes from v6: - Remove smmuv3 'pasid' attribute - Add smmuv3 'ssidsize' attribute - Add support for 'vpasidCapOffset' element - Modify logic for building accel smmuv3 qemu command line to omit ATS, RIL, accel flags when not needed (enabled/disabled by default in QEMU SMMUv3) [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VRSS… [1] https://lore.kernel.org/qemu-devel/20260126104342.253965-1-skolothumtho@nvi… Nathan Chen (2): qemu: Add support for HW-accelerated nested SMMUv3 tests: qemuxmlconfdata: provide HW-accel smmuv3 sample XML and CLI args docs/formatdomain.rst | 36 +++++++ src/conf/domain_conf.c | 101 +++++++++++++++++- src/conf/domain_conf.h | 6 ++ src/conf/domain_validate.c | 36 ++++++- src/conf/schemas/domaincommon.rng | 32 ++++++ src/qemu/qemu_command.c | 23 ++++ src/util/virpci.h | 4 + ...u-smmuv3-pci-bus-accel.aarch64-latest.args | 38 +++++++ ...mu-smmuv3-pci-bus-accel.aarch64-latest.xml | 64 +++++++++++ .../iommu-smmuv3-pci-bus-accel.xml | 54 ++++++++++ tests/qemuxmlconftest.c | 1 + 11 files changed, 390 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.xml -- 2.43.0

2 9

[PATCH 0/4] Add support for expanding CPU features in domain capabilities
by Jiri Denemark 11 Mar '26

11 Mar '26

Consistently with all other CPU definitions, domain capabilities report host-model CPU as a base model and additional list of features. Getting all features supported on a host is possible by passing the host-model CPU definition to hypervisor-cpu-baseline with --features option. But while this is very easy in virsh (domain capabilities can by directly piped to hypervisor-cpu-baseline), doing this via API is more complicated. The relevant part of the domain XML needs to be copied into a new XML document, formatted and passed to virConnectBaselineHypervisorCPU. This series adds the ability to expand CPU features directly in the domain capabilities XML without having to call another API. Jiri Denemark (4): Introduce EXPAND_CPU_FEATURES flag for domain capabilities qemu: Implement VIR_CONNECT_GET_DOMAIN_CAPABILITIES_EXPAND_CPU_FEATURES virsh: Add --expand-cpu-features option for domcapabilities docs: Clarify host-model description in domain capabilities docs/formatdomaincaps.rst | 4 ++++ docs/manpages/virsh.rst | 5 +++++ include/libvirt/libvirt-domain.h | 2 ++ src/libvirt-domain.c | 5 +++++ src/qemu/qemu_driver.c | 9 ++++++++- tools/virsh-host.c | 7 +++++++ 6 files changed, 31 insertions(+), 1 deletion(-) -- 2.53.0

2 5

[PATCH] tests: Create fake root dirs later
by Michal Privoznik 11 Mar '26

11 Mar '26

From: Michal Privoznik <mprivozn(a)redhat.com> In one of previous commits the virTestMain() function was changed to actually create fake HOME, XDG_RUNTIME_DIR, ... directories instead of setting spoofed values in the environment. But alongside with this, the call to virTestFakeRootDirInit() was moved (to location where environment was poisoned). And this would not matter if it wasn't for mocking. Because what we ended up with is virTestFakeRootDirInit() is called and then (optionally) the process re-execs itself (with mocks loaded). This means that previously created root dirs are never cleaned up and just pollute builddir. Therefore, restore original location from which the function was called. Fixes: 79d97d2b4f0b55ea80f8330144953e2b93927e25 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tests/testutils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/testutils.c b/tests/testutils.c index c984f66d0e..14e5c56fcf 100644 --- a/tests/testutils.c +++ b/tests/testutils.c @@ -859,9 +859,6 @@ int virTestMain(int argc, preloads[npreloads] = NULL; } - if (!(fakerootdir = virTestFakeRootDirInit())) - return EXIT_FAILURE; - va_start(ap, func); while ((lib = va_arg(ap, const char *))) { g_autofree char *abs_lib_path = g_strdup_printf("%s/%s", abs_builddir, lib); @@ -934,6 +931,9 @@ int virTestMain(int argc, failedTests = virBitmapNew(1); + if (!(fakerootdir = virTestFakeRootDirInit())) + return EXIT_FAILURE; + ret = (func)(); virResetLastError(); -- 2.52.0

2 1

[PATCH v2] scripts: dtrace2systemtap: Fix argument name extraction regex to avoid '*' in names
by Peter Krempa 11 Mar '26

11 Mar '26

From: Peter Krempa <pkrempa(a)redhat.com> When commit d249170bf609d2c modified the arguments of 'virNetTLSContextNew' which has a systemtap probe defined the 'dtrace2systemtap' script was no longer to correctly generate the definitions for it. First problem which stemmed from mis-detecting the string array argumment as string, which would use 'user_string' to extract it was fixed in cb33103c4afbce681. After that the generated probe is still not correct because it doesn't strip all the '*' from pointers and thus for double pointers it generates the following invalid definition: probe libvirt.rpc.tls_context_new = process("/usr/lib64/libvirt.so").mark("rpc_tls_context_new") { ctxt = $arg1; cacert = user_string($arg2); cacrl = user_string($arg3); *cert = $arg4; *keys = $arg5; sanityCheckCert = $arg6; requireValidCert = $arg7; isServer = $arg8; } Leading to the following failure: # stap -ve 'probe oneshot {exit()}' parse error: expected literal string or number saw: operator '*' at /usr/share/systemtap/tapset/libvirt_probes-64.stp:204:3 source: *cert = $arg4; ^ 1 parse error. To address the issue the regex extracting the arguments needs to optionally match any number of '*' instead of just one. Resolves: https://issues.redhat.com/browse/RHEL-153832 Fixes: cb33103c4afbce68134be112ecc5d0251e542650 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- scripts/dtrace2systemtap.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/dtrace2systemtap.py b/scripts/dtrace2systemtap.py index 361dab1075..12fc390bcd 100755 --- a/scripts/dtrace2systemtap.py +++ b/scripts/dtrace2systemtap.py @@ -127,7 +127,7 @@ for file in filelist: if re.match(r'''.*char\s\*[^\*].*''', arg) is not None: isstr = True - m = re.search(r'''^.*\s\*?(\S+)$''', arg) + m = re.search(r'''^.*\s\**(\S+)$''', arg) if m is not None: arg = m.group(1) else: -- 2.53.0

2 1

Failed to find parent device on Arrow Lake processor
by Bertrand Leconte 10 Mar '26

10 Mar '26

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/QRI4…. 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

6 17