February 2026 - Devel - libvirt List Archives

[PATCH v2 00/21] qom: introduce property flags to track external user input
by Zhao Liu 17 Mar '26

17 Mar '26

Hi, This is the v2 trying to introduce property flags to detect user's property setting (from CLI/QMP/HMP). I dropped RFC tag since previous RFC v1 [1]. Though this work the follow-up of v2.6 & v2.7 machines' removal [2], now it is decoupled from [2] totally since v2 doesn't detect compat property and only focuses on external user setting, so this series is based on master branch at the commit 28a6ca268c2c ("Merge tag 'single- binary-20260203' of https://github.com/philmd/qemu into staging"). And you can also find the code here: https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026 This series introduces 3 property flags: * USER_SET: Any external user property setting (from CLI/HMP/QMP) is marked as USER_SET. * DEPRECATED: Once a property is marked as DEPRECATED, any external user property setting will trigger a warning. * INTERNAL: Once a property is marked as INTERNAL, any external user property setting will cause an error. More details or document for these 3 flags, you can refer patch 7. Compared with RFC v1, v2 mainly: * introduce USER_SET property flag to identify all user's setting. - patch 7 for document. * construct DEPRECATED & INTERNAL flag on USER_SET. - patch 7 for document. * cover more comprehensive user set cases. - patch 8-13. * provide examples about new flags (USER_SET/DEPRECATED/INTELNAL). - patch 15/16/17 are examples for DEPRECATED flag. - patch 18 is the example for INTERNAL flag. - patch 20 is the example for USER_SET flag. I think v2 should now cover "nearly" all cases (patch 8-13) where users set properties: one approach is to trace the call chain of object_property_set(). Even if there are cases that were missed, they can be easily addressed based on this series: object_property_set(obj, ...); /* Insert this call after object_property_set(). */ object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...); [1]: RFC v1: https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel… [2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.… Thanks and Best Regards, Zhao --- Zhao Liu (21): qom/object: use BIT macro for ObjectPropertyFlags qom/object: cache ObjectPropertyFlags in ObjectProperty qom/object: factor out object_class_property_try_add() qom/object: add flags argument in object_{class_}property_try_add() qom/object: rename object_{class_}property_try_add() to object_{class_}property_add_full() qom/object: add helpers to set/get/clear property flags qom/object: introduce user interaction flags for properties qom/object: add from_user argument in object_property_parse() qom/object: mark global property set from CLI as USER_SET qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as USER_SET qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as USER_SET qom/object_interfaces: mark properties set from qdict & keyval as USER_SET system/vl: mark property set in object_parse_property_opt() as USER_SET hw/core/qdev-properties: allow qdev properties accept flags target/i386: deprecate fill-mtrr-mask property target/i386: deprecate cpuid-0xb property hw/intc/ioapic: deprecate version property target/i386: mark x-consistent-cache property as internal-only target/i386: remove redundant validation for lbr-fmt property target/i386: detect user provided lbr-fmt via property flag hw/core/qdev-properties: support valid default value for DEFINE_PROP_UINT64_CHECKMASK docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-) -- 2.34.1

7 40

[PATCH 0/4] libvirt: AMD IOMMU fixes
by Xiaotian Feng 14 Mar '26

14 Mar '26

This series refines libvirt's logic for large vCPU configurations (>255) on x86/q35 machine types. Historically, the threshold was tied to Intel's EIM capability, but the real requirement is x2APIC support for APIC IDs beyond 255. AMD platforms can satisfy this via xtsup on amd-iommu. Summary of changes: 1. Fix virDomainIOMMUDefEquals to include pt and xtsup attributes for proper checks. 2. Correct error messages for passthrough (pt) and xtsup attributes to reflect their actual names instead of "dma translation". 3. Rename QEMU_MAX_VCPUS_WITHOUT_EIM to QEMU_MAX_VCPUS_WITHOUT_X2APIC and update validation logic to accept either: - intel-iommu with eim='on', or - amd-iommu with xtsup='on' for guests with more than 255 vCPUs. Error messages now mention x2APIC mode instead of extended interrupt mode. 4. Add QEMU_CAPS_AMD_IOMMU_XTSUP capability and enable xtsup by default for AMD IOMMU when a Q35 domain has >255 vCPUs, similar to Intel EIM auto-enable logic. Also ensure intremap is turned on when required. This makes the behavior vendor-neutral and improves usability for AMD EPYC guests with large vCPU counts. No ABI changes beyond stricter equality checks; this is a clarification and extension of existing logic. Xiaotian Feng (4): conf: fix virDomainIOMMUDefEquals for amd_iommu conf: fix error log for passthrough and xtsup attributes conf: support >255 vcpu w/ amd-iommu xtsup qemu: Enable AMD IOMMU XTSUP by default src/conf/domain_conf.c | 6 ++++-- src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_postparse.c | 42 +++++++++++++++++++++++------------- src/qemu/qemu_validate.c | 11 +++++----- src/qemu/qemu_validate.h | 2 +- 6 files changed, 41 insertions(+), 23 deletions(-) -- 2.34.1

2 6

[PATCH] storage: mpath: fix error reporting in virStorageBackendGetMaps
by Lucas Amaral 14 Mar '26

14 Mar '26

virStorageBackendGetMaps() returns 1 on failure instead of the conventional -1, and does not call virReportError() in any of its error paths. On top of that, both callers silently discard the return value: virStorageBackendGetMaps() ignores the result of virStorageBackendCreateVols(), and virStorageBackendMpathRefreshPool() ignores the result of virStorageBackendGetMaps(). Fix all three issues: normalize error returns to -1, add virReportError() calls for each failure path in virStorageBackendGetMaps(), and check return values in both callers so that errors are properly propagated. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- This is similar in spirit to commits e9b931d3e4 ("virpci: Report an error if virPCIGetVirtualFunctionIndex() fails") and 6c2c9e21ac ("virstorageobj: Make virStoragePoolObjAddVol() report an error on failure"), applying the same pattern to the mpath storage backend. Found while auditing storage backends for functions that return error codes without calling virReportError(). src/storage/storage_backend_mpath.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c index 9fc3983c52..a30153a93b 100644 --- a/src/storage/storage_backend_mpath.c +++ b/src/storage/storage_backend_mpath.c @@ -197,19 +197,25 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) struct dm_names *names = NULL; if (!(dmt = dm_task_create(DM_DEVICE_LIST))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to create devmapper task")); + retval = -1; goto out; } dm_task_no_open_count(dmt); if (!dm_task_run(dmt)) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to run devmapper task")); + retval = -1; goto out; } if (!(names = dm_task_get_names(dmt))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get devmapper device names")); + retval = -1; goto out; } @@ -218,7 +224,10 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) goto out; } - virStorageBackendCreateVols(pool, names); + if (virStorageBackendCreateVols(pool, names) < 0) { + retval = -1; + goto out; + } out: if (dmt != NULL) @@ -248,7 +257,8 @@ virStorageBackendMpathRefreshPool(virStoragePoolObj *pool) virWaitForDevices(); - virStorageBackendGetMaps(pool); + if (virStorageBackendGetMaps(pool) < 0) + return -1; return 0; } -- 2.52.0

2 1

[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 v7 0/2] qemu: Support accelerated vSMMUs
by Nathan Chen 12 Mar '26

12 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

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

11 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

Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev properties accept flags
by Daniel P. Berrangé 09 Mar '26

09 Mar '26

On Wed, Feb 11, 2026 at 03:30:06PM +0800, Zhao Liu wrote: > On Tue, Feb 10, 2026 at 09:56:08AM +0000, Daniel P. Berrangé wrote: > > Date: Tue, 10 Feb 2026 09:56:08 +0000 > > From: "Daniel P. Berrangé" <berrange(a)redhat.com> > > Subject: Re: [PATCH v2 14/21] hw/core/qdev-properties: allow qdev > > properties accept flags > > > > On Tue, Feb 10, 2026 at 11:23:41AM +0800, Zhao Liu wrote: > > > Update qdev property interfaces (qdev_property_add_static() and > > > qdev_class_add_property()) to accept and pass 'ObjectPropertyFlags'. > > > This enables marking qdev properties with flags such as DEPRECATED or > > > INTERNAL. > > > > > > To facilitate this at the definition level, extend the boolean and > > > uint8_t property macros (as the examples) to accept variable arguments > > > (VA_ARGS). This allows callers to optionally specify flags in the > > > property definition. > > > > > > Example: > > > > > > DEFINE_PROP_UINT8("version", IOAPICCommonState, version, IOAPIC_VER_DEF, > > > .flags = OBJECT_PROPERTY_DEPRECATED), > > > > In other places where we track deprecation in QEMU, we have not used > > a boolean flag. Instead we have used a "const char *deprecation_note" > > internally, which lets us provide a user facing message, to be printed > > out in the warn_report, informing them what to do instead (either the > > feature is entirely removed, or there is a better alternative). IMHO > > we should be following the same pattern for properties, as it is much > > more user friendly than just printing a totally generic message > > "XXXX is deprecated, stop using it" > > Yes, rich deprecation hint is better. I think this still depends on > USER_SET - distinguish internal/external or not :-(. > > Since when we mark a property as deprecated, its code remains in the > code tree, and internal calls should not trigger warnings. Deprecation > hints are intended to reminder external users. This depends on where you put the deprecation check. IIUC, all the user facing codepaths for setting properties end up calling through object_set_properties_from_qdict, but internal codepaths don't use that. That method can check & emit the deprecation warnings, without us needing any explicit tracking of "user set" - the use context is derived from the codepath 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 :|

4 8

[PATCH 0/4] qemuhotplugtest: Introduce interface-hostdev test case
by Michal Privoznik 09 Mar '26

09 Mar '26

Inspired by the following patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/YQHQ… Michal Prívozník (4): virpcimock: Create sriov_totalvfs file and virtfnN symlinks virpcimock: Create net/ subdir for devices virnetdevmock: Mock virNetDevSaveNetConfig() and virNetDevSetNetConfig() qemuhotplugtest: Introduce interface-hostdev test case src/util/virnetdev.h | 5 +- tests/qemuhotplugtest.c | 7 +- .../qemuhotplug-interface-hostdev.xml | 6 ++ ...emuhotplug-base-live+interface-hostdev.xml | 63 +++++++++++++++ tests/virnetdevmock.c | 22 ++++++ tests/virpcimock.c | 78 +++++++++++++++++-- 6 files changed, 171 insertions(+), 10 deletions(-) create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-interface-hostdev.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+interface-hostdev.xml -- 2.52.0

2 5

[PATCH 0/6] qemu: fix a passt bug, add a passt feature
by Laine Stump 09 Mar '26

09 Mar '26

The first patch cleans up a dangling socket that was hanging around after we finished using a passt process in vhostuser mode. The rest are to support specifying the default route for a passt interface with <route gateway='x.x.x.x'/> Laine Stump (6): qemu: delete passt "repair" socket when appropriate qemu: reorganize qemuValidateDomainDeviceDefNetwork() qemu: only limit IPv4 prefix for slirp util: make the route arg to virNetDevIPRouteGetPrefix const conf/util: fix non-specification of IP route destination address qemu: support setting default route for passt interfaces inside the guest src/conf/networkcommon_conf.c | 74 ++++++++------- src/conf/schemas/networkcommon.rng | 4 +- src/qemu/qemu_passt.c | 30 ++++++- src/qemu/qemu_validate.c | 140 +++++++++++++++++++---------- src/util/virnetdevip.c | 14 ++- src/util/virnetdevip.h | 2 +- 6 files changed, 170 insertions(+), 94 deletions(-) -- 2.52.0

3 17

[PATCH 1/2] hyperv: fix flags passed to virDomainDefParseString()
by Jonathon Jongsma 06 Mar '26

06 Mar '26

This function expects flags that are bitwise-or values of the VIR_DOMAIN_DEF_PARSE_* constants, but we were passing two flags that were not part of this flag set: - 1 < VIR_DOMAIN_VIRT_HYPERV - VIR_DOMAIN_XML_INACTIVE Replace VIR_DOMAIN_XML_INACTIVE with VIR_DOMAIN_DEF_PARSE_INACTIVE (which fortunately happens to be the exact same value). Remove flag "1 < VIR_DOMAIN_VIRT_HYPERV", which turns out to the the same value as the flag VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION, which seems unnecessary and undesirable here. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/hyperv/hyperv_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hyperv/hyperv_driver.c b/src/hyperv/hyperv_driver.c index b01b4919fe..8832769c7b 100644 --- a/src/hyperv/hyperv_driver.c +++ b/src/hyperv/hyperv_driver.c @@ -2937,7 +2937,7 @@ hypervDomainDefineXML(virConnectPtr conn, const char *xml) /* parse xml */ def = virDomainDefParseString(xml, priv->xmlopt, NULL, - 1 << VIR_DOMAIN_VIRT_HYPERV | VIR_DOMAIN_XML_INACTIVE); + VIR_DOMAIN_DEF_PARSE_INACTIVE); if (!def) goto error; -- 2.53.0

2 2