- Devel - libvirt List Archives

[PATCH 0/2] Fix crash when reverting/deleting external inactive snapshots around the root of the snapshot tree
by Peter Krempa 23 Jan '26

23 Jan '26

Peter Krempa (2): qemuSnapshotDiskHasBackingDisk: Avoid call of virStorageSourceIsSameLocation with NULL argument qemuSnapshotUpdateBackingStore: Remove stale comment src/qemu/qemu_snapshot.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.52.0

2 3

[PATCH v3 0/2] Include test cases for virSocketAddrFormatWithPrefix
by Julio Faracco 23 Jan '26

23 Jan '26

Recently, we removed the masked argument in commit 6f07a8e6 from the respective function. But, in sockettest.c, we don't have any test case to cover this function. This series adds some test cases for virSocketAddrFormatWithPrefix and an extra patch to increase the testFormat debugging info. Julio Faracco (2): tests: Add tests for virSocketAddrFormatWithPrefix tests: Add debug information in testFormat() tests/sockettest.c | 77 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 76 insertions(+), 1 deletion(-) -- 2.52.0

1 2

[PATCH] Standardize socket family checks with proper macro
by Julio Faracco 23 Jan '26

23 Jan '26

There is a macro called VIR_SOCKET_ADDR_IS_FAMILY that checks the socket family. There are several occurrences of raw checks in libvirt code. This commit just standardizes the socket family checks by using its macro. Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com> --- src/rpc/virnetsocket.c | 20 ++++++++++---------- src/util/virsocketaddr.c | 4 ++-- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index e8fc2d5f7d..22b0aa6ead 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -276,8 +276,8 @@ virNetSocketNew(virSocketAddr *localAddr, sock->unlinkUNIX = unlinkUNIX; /* Disable nagle for TCP sockets */ - if (sock->localAddr.data.sa.sa_family == AF_INET || - sock->localAddr.data.sa.sa_family == AF_INET6) { + if (VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_INET) || + VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_INET6)) { if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &no_slow_start, sizeof(no_slow_start)) < 0) { @@ -405,9 +405,9 @@ int virNetSocketNewListenTCP(const char *nodename, * other IP protocol */ if (port != 0 && service == NULL) { - if (addr.data.sa.sa_family == AF_INET) { + if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET)) { addr.data.inet4.sin_port = port; - } else if (addr.data.sa.sa_family == AF_INET6) { + } else if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET6)) { addr.data.inet6.sin6_port = port; } VIR_DEBUG("Used saved port %d", port); @@ -432,9 +432,9 @@ int virNetSocketNewListenTCP(const char *nodename, } if (port == 0 && service == NULL) { - if (addr.data.sa.sa_family == AF_INET) + if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET)) port = addr.data.inet4.sin_port; - else if (addr.data.sa.sa_family == AF_INET6) + else if (VIR_SOCKET_ADDR_IS_FAMILY(&addr, AF_INET6)) port = addr.data.inet6.sin6_port; VIR_DEBUG("Saved port %d", port); } @@ -1293,7 +1293,7 @@ void virNetSocketDispose(void *obj) #ifndef WIN32 /* If a server socket, then unlink UNIX path */ if (sock->unlinkUNIX && - sock->localAddr.data.sa.sa_family == AF_UNIX && + VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX) && sock->localAddr.data.un.sun_path[0] != '\0') unlink(sock->localAddr.data.un.sun_path); #endif @@ -1370,7 +1370,7 @@ bool virNetSocketIsLocal(virNetSocket *sock) { bool isLocal = false; virObjectLock(sock); - if (sock->localAddr.data.sa.sa_family == AF_UNIX) + if (VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX)) isLocal = true; virObjectUnlock(sock); return isLocal; @@ -1381,7 +1381,7 @@ bool virNetSocketHasPassFD(virNetSocket *sock) { bool hasPassFD = false; virObjectLock(sock); - if (sock->localAddr.data.sa.sa_family == AF_UNIX) + if (VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX)) hasPassFD = true; virObjectUnlock(sock); return hasPassFD; @@ -2223,7 +2223,7 @@ void virNetSocketClose(virNetSocket *sock) #ifndef WIN32 /* If a server socket, then unlink UNIX path */ if (sock->unlinkUNIX && - sock->localAddr.data.sa.sa_family == AF_UNIX && + VIR_SOCKET_ADDR_IS_FAMILY(&sock->localAddr, AF_UNIX) && sock->localAddr.data.un.sun_path[0] != '\0') { if (unlink(sock->localAddr.data.un.sun_path) == 0) sock->localAddr.data.un.sun_path[0] = '\0'; diff --git a/src/util/virsocketaddr.c b/src/util/virsocketaddr.c index 4d4a6b2a0f..e8e691ce8f 100644 --- a/src/util/virsocketaddr.c +++ b/src/util/virsocketaddr.c @@ -481,7 +481,7 @@ virSocketAddrFormatFull(const virSocketAddr *addr, /* Short-circuit since getnameinfo doesn't work * nicely for UNIX sockets */ - if (addr->data.sa.sa_family == AF_UNIX) { + if (VIR_SOCKET_ADDR_IS_FAMILY(addr, AF_UNIX)) { if (withService) { addrstr = g_strdup_printf(VIR_LOOPBACK_IPV4_ADDR "%s0", separator ? separator : ":"); @@ -636,7 +636,7 @@ virSocketAddrGetPath(virSocketAddr *addr G_GNUC_UNUSED) return NULL; } - if (addr->data.sa.sa_family != AF_UNIX) { + if (!VIR_SOCKET_ADDR_IS_FAMILY(addr, AF_UNIX)) { virReportError(VIR_ERR_INVALID_ARG, "%s", _("UNIX socket address is required")); return NULL; -- 2.52.0

2 2

[PATCH v2 0/2] Remove @masked argument from virSocketAddrFormatWithPrefix
by Julio Faracco 23 Jan '26

23 Jan '26

Since its introduction in commit 426afc00, the function virSocketAddrFormatWithPrefix has never been called with argument masked=false. So, this commit proposes to remove this unnecessary argument from the function scope. This series also proposes the respective test cases for virSocketAddrFormatWithPrefix (now, without @masked argument). Julio Faracco (2): util: Remove @masked argument from virSocketAddrFormatWithPrefix tests: Add tests for virSocketAddrFormatWithPrefix src/network/network_iptables.c | 10 +++--- src/network/network_nftables.c | 10 +++--- src/util/virsocketaddr.c | 14 ++++---- src/util/virsocketaddr.h | 3 +- tests/sockettest.c | 63 ++++++++++++++++++++++++++++++++++ 5 files changed, 80 insertions(+), 20 deletions(-) -- 2.52.0

2 5

[PATCH 0/6] virtio-iommu: Support setting aw-bits and granule
by Michal Privoznik 23 Jan '26

23 Jan '26

*** BLURB HERE *** Michal Prívozník (6): qemu_capabilities: Introduce QEMU_CAPS_VIRTIO_IOMMU_AW_BITS conf: Allow aw_bits for virtio-iommu qemu_command: Generate aw_bits prop for virtio-iommu conf: Introduce granule attribute for virtio-iommu qemu_validate: Check whether granule of virtio-iommu is supported qemu_command: Generate granule prop for virtio-iommu docs/formatdomain.rst | 9 +++++- src/conf/domain_conf.c | 30 ++++++++++++++++++- src/conf/domain_conf.h | 13 ++++++++ src/conf/domain_validate.c | 18 +++++++---- src/conf/schemas/domaincommon.rng | 11 +++++++ src/libvirt_private.syms | 2 ++ src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 7 +++++ src/qemu/qemu_validate.c | 13 ++++++-- .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_s390x.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../caps_10.1.0_s390x.xml | 1 + .../caps_10.1.0_x86_64+inteltdx.xml | 1 + .../caps_10.1.0_x86_64.xml | 1 + .../caps_10.2.0_aarch64.xml | 1 + .../caps_10.2.0_x86_64+mshv.xml | 1 + .../caps_10.2.0_x86_64.xml | 1 + .../caps_11.0.0_aarch64.xml | 1 + .../caps_11.0.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_riscv64.xml | 1 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + .../virtio-iommu-aarch64.aarch64-latest.args | 2 +- .../virtio-iommu-aarch64.aarch64-latest.xml | 1 + .../qemuxmlconfdata/virtio-iommu-aarch64.xml | 4 ++- ...io-iommu-dma-translation.x86_64-latest.err | 2 +- 35 files changed, 124 insertions(+), 12 deletions(-) -- 2.52.0

3 18

[PATCH] Fix printf style used with virDomainIOMMUDef::aw_bits
by Michal Privoznik 22 Jan '26

22 Jan '26

From: Michal Privoznik <mprivozn(a)redhat.com> The aw_bits member of the virDomainIOMMUDef is of type unsigned int. However, in a few places (virDomainIOMMUDefCheckABIStability(), virDomainIOMMUDefFormat(), qemuBuildIOMMUCommandLine()) incorrect printf modifier is used. Fix those places. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.c | 4 ++-- src/qemu/qemu_command.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 8b26de674e..9672168df9 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -22301,7 +22301,7 @@ virDomainIOMMUDefCheckABIStability(virDomainIOMMUDef *src, } if (src->aw_bits != dst->aw_bits) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("Target domain IOMMU device aw_bits value '%1$d' does not match source '%2$d'"), + _("Target domain IOMMU device aw_bits value '%1$u' does not match source '%2$u'"), dst->aw_bits, src->aw_bits); return false; } @@ -28638,7 +28638,7 @@ virDomainIOMMUDefFormat(virBuffer *buf, virTristateSwitchTypeToString(iommu->iotlb)); } if (iommu->aw_bits > 0) { - virBufferAsprintf(&driverAttrBuf, " aw_bits='%d'", + virBufferAsprintf(&driverAttrBuf, " aw_bits='%u'", iommu->aw_bits); } if (iommu->dma_translation != VIR_TRISTATE_SWITCH_ABSENT) { diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 0de0a79b46..e81efdfde7 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6295,7 +6295,7 @@ qemuBuildIOMMUCommandLine(virCommand *cmd, "T:caching-mode", iommu->caching_mode, "S:eim", qemuOnOffAuto(iommu->eim), "T:device-iotlb", iommu->iotlb, - "z:aw-bits", iommu->aw_bits, + "p:aw-bits", iommu->aw_bits, "T:dma-translation", iommu->dma_translation, NULL) < 0) return -1; -- 2.52.0

2 1

[RFC PATCH v5 0/5] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 22 Jan '26

22 Jan '26

Hi, all. This patch adds Arm CCA support to QEMU driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. We are not yet at the stage where we can merge this patch as host Linux/QEMU support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v5: - Changed the target QEMU binary (Linaro's CCA/v10 version with added QMP functionality) - Changed the following changes to the CCA QMP command definitions: - QMP command name: query-rme-guest-capabilities - CCA capabilities info - Add ARM CCA support to firmware feature. [summary] At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. capability info uses QEMU QMP to query QEMU options. The option that exists now is for selecting a hash algorithm. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [Capability example] Execution results of 'virsh domcapability" on QEMU <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] To obtain capability info, it is necessary to support the QEMU QMP command, (See "[software version]"below). The JSON file for the CCA firmware feature has not yet been provided by the distributor. For CCA support, the equivalent of the following JSON file must be placed in /usr/share/qemu: tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the virsh create command. [software version] I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… The QEMU used was enhanced with CCA QMP command and found at: https://gitlab.com/Linaro/dcap/qemu/-/commits/cca/latest RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… RFC v3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LLWA… RFC v4 https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3WAW… Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com Akio Kakuno (3): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema Kazuhiro Abe (2): src: Add ARM CCA support in firmware feature tests: Adds Arm CCA support docs/formatdomain.rst | 46 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 146 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 30 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 18 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 111 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_10.1.0-virt.aarch64+armrme.xml | 250 + .../qemu_10.1.0.aarch64+armrme.xml | 250 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_10.1.0_aarch64+armrme.replies | 37727 ++++++++++++++++ .../caps_10.1.0_aarch64+armrme.xml | 518 + .../qemu/firmware/50-edk2-aarch64-armcca.json | 24 + tests/qemufirmwaretest.c | 3 + ...ch-security-cca.aarch64-latest+armrme.args | 30 + ...nch-security-cca.aarch64-latest+armrme.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 36 files changed, 39423 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_10.1.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.xml create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.0

1 5

[PATCH v1 0/4] Adding support for client-based FD migrations.
by Tejus GK 22 Jan '26

22 Jan '26

Libvirt supports FD-based live migrations in the form of tunnelled migrations. However, this isn't as performant as of now, since it involves extra copies. This patchset proposes adding support for externally provided file descriptors for live migration. By allowing the client to supply the migration FD directly, the extra copy can be avoided, improving overall migration performance. The intent is to gather early feedback on the approach and its feasibility. Comments, concerns, and suggestions are very welcome :) regards, Tejus Tejus GK (4): qemu: fd: introduce qemuFDTuple for FD storage lib: introduce virDomainFDStore API qemu: support incoming "fd" uri qemu: add support for fd based live migrations include/libvirt/libvirt-domain.h | 9 +++ src/driver-hypervisor.h | 7 ++ src/libvirt-domain.c | 62 +++++++++++++++ src/libvirt_public.syms | 5 ++ src/qemu/qemu_conf.h | 4 + src/qemu/qemu_driver.c | 41 ++++++++++ src/qemu/qemu_fd.c | 23 ++++++ src/qemu/qemu_fd.h | 14 ++++ src/qemu/qemu_migration.c | 117 +++++++++++++++++++++++++++- src/remote/remote_daemon_dispatch.c | 36 +++++++++ src/remote/remote_driver.c | 22 ++++++ src/remote/remote_protocol.x | 12 ++- 12 files changed, 348 insertions(+), 4 deletions(-) -- 2.43.7

2 11

[PATCH 0/2] src: Use device alias when ifname is unset in virDomainInterfaceAddresses()
by Michal Privoznik 21 Jan '26

21 Jan '26

*** BLURB HERE *** Michal Prívozník (2): libvirt-domain: Fix documentation of virDomainInterfaceAddresses() src: Use device alias when ifname is unset in virDomainInterfaceAddresses() src/conf/domain_conf.c | 16 ++++++++++++++-- src/libvirt-domain.c | 4 +++- 2 files changed, 17 insertions(+), 3 deletions(-) -- 2.52.0

2 3

[RFC] Reintroducing customisable hotplug timeouts
by Akash Kulhalli 20 Jan '26

20 Jan '26

I'd like to resurface an earlier proposal [1] to make the unplug timeout user-configurable. With production guests running sustained, non-trivial workloads, we find that hot(un)plug operations regularly takes longer than the current default of 5s. However, the inability to easily configure this timeout means that in the worst case a recompilation with appropriate values set is required for each deployment, which is cumbersome to maintain and patch. The previous proposal [1] also initially made the timeout configurable, however that was specifically for the ppc64 architecture. Therefore, imposing this change for an entire architecture made sense, since it was a universal requirement for that platform. With deployment environments as diverse and varied as x86, having a single, inconfigurable value does not make as much sense now. For x86, such a change is not ideal since the desired timeout value depends very heavily on the deployment environment in use - if it is being performed by a human anything more than 10s is an undesirable user experience [2], as pointed out in the original discussion. However, more relaxed timeout values (e.g. 15-20s) can be more acceptable if the operations are background/ not directly user-facing. It is in these cases where the ability to change the timeout more easily becomes more desirable. To prevent misconfiguration, while maintaining the same out-of-box experience for existing users, I'd also like to propose the following- 1. As mentioned in the original proposal [1], the timeout cannot be set to a value lower than the default timeout of 5s; in these cases a warning will be emitted and the timeout will be reset to the default value. 2. Including an upper cap would also be desirable, in my opinion - any API consumer should not wait endlessly for an async operation to finish. 3. This configuration option will only be described in qemu.conf, not imposed - the out-of-box experience will remain unchanged at the current default (5s) for everyone who does not wish to tweak/is unaware of this value. An administrator who knowingly changes these values is therefore not blindsided by any perceived "hangs" resulting from the use of an increased timeout window. Since this would be a clearly documented and explicitly opt-in behaviour, the benefits in the form of easy modification based on evolving operational needs would be quite significant. Given the varying nature of production environments and specific operational needs at scale, it would therefore be beneficial to reconsider the merits of the original proposal. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/TXYV… [2] https://www.nngroup.com/articles/response-times-3-important-limits/

4 5