- Devel - libvirt List Archives

Re: [PATCH 2/6] system/hostmem: Remove HostMemoryBackend::use_canonical_path field
by Thomas Huth 10 Mar '26

10 Mar '26

On 07/03/2026 16.41, Philippe Mathieu-Daudé wrote: > The HostMemoryBackend::use_canonical_path boolean > was only set in the hw_compat_3_1[] array, via the > 'x-use-canonical-path-for-ramblock-id=true' property. > We removed all machines using that array, but the > comment added in commit 8db0b20415c ("machine: add > missing doc for memory-backend option") requested to > not remove this property "as long as 4.0 and older > machine types exists". Previous commit removed the > last machines in this range, we can now remove that > property and all the code around it. > > Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> > --- > qapi/qom.json | 8 +------- > include/system/hostmem.h | 2 +- > backends/hostmem.c | 34 ---------------------------------- > qemu-options.hx | 10 ---------- > 4 files changed, 2 insertions(+), 52 deletions(-) > > diff --git a/qapi/qom.json b/qapi/qom.json > index c653248f85d..3e13e3fd25c 100644 > --- a/qapi/qom.json > +++ b/qapi/qom.json > @@ -660,11 +660,6 @@ > # > # @size: size of the memory region in bytes > # > -# @x-use-canonical-path-for-ramblock-id: if true, the canonical path > -# is used for ramblock-id. Disable this for 4.0 machine types or > -# older to allow migration with newer QEMU versions. > -# (default: false generally, but true for machine types <= 4.0) > -# > # .. note:: prealloc=true and reserve=false cannot be set at the same > # time. With reserve=true, the behavior depends on the operating > # system: for example, Linux will not reserve swap space for shared > @@ -683,8 +678,7 @@ > '*prealloc-context': 'str', > '*share': 'bool', > '*reserve': 'bool', > - 'size': 'size', > - '*x-use-canonical-path-for-ramblock-id': 'bool' } } > + 'size': 'size' } } > > ## > # @MemoryBackendFileProperties: > diff --git a/include/system/hostmem.h b/include/system/hostmem.h > index 88fa791ac78..cafcf9c9c74 100644 > --- a/include/system/hostmem.h > +++ b/include/system/hostmem.h > @@ -74,7 +74,7 @@ struct HostMemoryBackend { > > /* protected */ > uint64_t size; > - bool merge, dump, use_canonical_path; > + bool merge, dump; > bool prealloc, is_mapped, share, reserve; > bool guest_memfd, aligned; > uint32_t prealloc_threads; > diff --git a/backends/hostmem.c b/backends/hostmem.c > index 15d4365b697..7da7cd54e05 100644 > --- a/backends/hostmem.c > +++ b/backends/hostmem.c > @@ -40,10 +40,6 @@ QEMU_BUILD_BUG_ON(HOST_MEM_POLICY_INTERLEAVE != MPOL_INTERLEAVE); > char * > host_memory_backend_get_name(HostMemoryBackend *backend) > { > - if (!backend->use_canonical_path) { > - return g_strdup(object_get_canonical_path_component(OBJECT(backend))); > - } I'm a little bit confused by this one here. If I've got that right, the flag was set to "true" for the old QEMU machines <= 3.1, and it is set to false by default for new machines? If so, shouldn't we rather always use the above return and remove the one below instead? > return object_get_canonical_path(OBJECT(backend)); > } > > @@ -484,23 +480,6 @@ static void host_memory_backend_set_reserve(Object *o, bool value, Error **errp) > } > #endif /* CONFIG_LINUX */ > > -static bool > -host_memory_backend_get_use_canonical_path(Object *obj, Error **errp) > -{ > - HostMemoryBackend *backend = MEMORY_BACKEND(obj); > - > - return backend->use_canonical_path; > -} > - > -static void > -host_memory_backend_set_use_canonical_path(Object *obj, bool value, > - Error **errp) > -{ > - HostMemoryBackend *backend = MEMORY_BACKEND(obj); > - > - backend->use_canonical_path = value; > -} > - > static void > host_memory_backend_class_init(ObjectClass *oc, const void *data) > { > @@ -563,19 +542,6 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data) > object_class_property_set_description(oc, "reserve", > "Reserve swap space (or huge pages) if applicable"); > #endif /* CONFIG_LINUX */ > - /* > - * Do not delete/rename option. This option must be considered stable > - * (as if it didn't have the 'x-' prefix including deprecation period) as > - * long as 4.0 and older machine types exists. By the way, this option seems to be used by libvirt - we should maybe make sure that its removal does not break libvirt by accident...? Thomas

2 1

[PATCH 0/4] qemu: bump qemu capabilities and use 'flat' mode of 'query-block'
by Peter Krempa 10 Mar '26

10 Mar '26

Peter Krempa (4): qemucapabilitiestest: Update 'caps_11.0.0_x86_64' to 'v10.2.0-2062-g084a6c6e73" qemucapabilitiestest: Update 'caps_11.0.0_aarch64' to 'v10.2.0-2062-g084a6c6e73"aarch qemu: capabilities: Introduce QEMU_CAPS_QUERY_BLOCK_FLAT qemu: monitor: Use 'flat' mode of 'query-block' src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_monitor.c | 1 + src/qemu/qemu_monitor_json.c | 12 +- src/qemu/qemu_monitor_priv.h | 3 + .../caps_11.0.0_aarch64.replies | 5587 ++++++++-------- .../caps_11.0.0_aarch64.xml | 39 +- .../caps_11.0.0_x86_64.replies | 5815 +++++++++-------- .../caps_11.0.0_x86_64.xml | 287 +- 9 files changed, 6254 insertions(+), 5493 deletions(-) -- 2.53.0

3 6

[PATCH] docs: storage: Note that refreshing the storage pool is needed on outside modification
by Peter Krempa 10 Mar '26

10 Mar '26

From: Peter Krempa <pkrempa(a)redhat.com> Add a note stating that pool contents and metadata are not auto-updated when the pool is modified outside of libvirt. Closes: https://gitlab.com/libvirt/libvirt/-/work_items/749 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatstorage.rst | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/formatstorage.rst b/docs/formatstorage.rst index 9d9a4143eb..7ed57732af 100644 --- a/docs/formatstorage.rst +++ b/docs/formatstorage.rst @@ -25,6 +25,13 @@ attribute ``type``, which is one of ``dir``, ``fs``, ``netfs``, ``disk``, ``iscsi-direct`` ( :since:`since 4.7.0` ). This corresponds to the storage backend drivers listed further along in this document. + .. note:: + Any modification of the storage pool outside of libvirt or on a different + host for shared storage pools may not update the cached volume or pool + metadata. The pool metadata can be refreshed by calling + ``virsh pool-refresh POOLNAME`` or by the + `virStoragePoolRefresh <html/libvirt-libvirt-storage.html#virStoragePoolRefresh>`__ API. + Storage pool general metadata ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.53.0

2 1

[libvirt PATCH] qemu_hotplug: Fix crash when attaching network inteface with hostdev network
by Pavel Hrdina 10 Mar '26

10 Mar '26

From: Pavel Hrdina <phrdina(a)redhat.com> The following interface XML will crash libvirt when attached to running VM: <interface type='network'> <source network='hostdev_net'/> </interface> Instead of trying to figure out every single place where hostdev is used as struct directly and allocating empty private data check if iommufd is configured as that will happen only for <hostdev> device where the private data are correctly allocated. This patch is best viewed with `git show -w`. Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/qemu/qemu_hotplug.c | 37 +++++++++++++++++++++---------------- 1 file changed, 21 insertions(+), 16 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b3f2a173a8..966e746f2b 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1630,20 +1630,23 @@ qemuDomainAttachHostPCIDevice(virQEMUDriver *driver, qemuDomainObjEnterMonitor(vm); - if (objprops) { - if ((ret = qemuFDPassDirectTransferMonitor(priv->iommufd, priv->mon)) < 0) - goto exit_monitor; - if ((ret = qemuMonitorAddObject(priv->mon, &objprops, NULL)) < 0) - goto exit_monitor; + if (virHostdevIsPCIDeviceWithIOMMUFD(hostdev)) { + if (objprops) { + if ((ret = qemuFDPassDirectTransferMonitor(priv->iommufd, priv->mon)) < 0) + goto exit_monitor; + + if ((ret = qemuMonitorAddObject(priv->mon, &objprops, NULL)) < 0) + goto exit_monitor; - priv->iommufdState = true; - removeiommufd = true; + priv->iommufdState = true; + removeiommufd = true; + } + + if ((ret = qemuFDPassDirectTransferMonitor(hostdevPriv->vfioDeviceFd, priv->mon)) < 0) + goto exit_monitor; } - if ((ret = qemuFDPassDirectTransferMonitor(hostdevPriv->vfioDeviceFd, priv->mon)) < 0) - goto exit_monitor; - if ((ret = qemuDomainAttachExtensionDevice(priv->mon, hostdev->info)) < 0) goto exit_monitor; @@ -1674,15 +1677,17 @@ qemuDomainAttachHostPCIDevice(virQEMUDriver *driver, if (teardownmemlock && qemuDomainAdjustMaxMemLock(vm) < 0) VIR_WARN("Unable to reset maximum locked memory on hotplug fail"); - qemuDomainObjEnterMonitor(vm); + if (virHostdevIsPCIDeviceWithIOMMUFD(hostdev)) { + qemuDomainObjEnterMonitor(vm); - if (removeiommufd) - ignore_value(qemuMonitorDelObject(priv->mon, "iommufd0", false)); + if (removeiommufd) + ignore_value(qemuMonitorDelObject(priv->mon, "iommufd0", false)); - qemuFDPassDirectTransferMonitorRollback(hostdevPriv->vfioDeviceFd, priv->mon); - qemuFDPassDirectTransferMonitorRollback(priv->iommufd, priv->mon); + qemuFDPassDirectTransferMonitorRollback(hostdevPriv->vfioDeviceFd, priv->mon); + qemuFDPassDirectTransferMonitorRollback(priv->iommufd, priv->mon); - qemuDomainObjExitMonitor(vm); + qemuDomainObjExitMonitor(vm); + } if (releaseaddr) qemuDomainReleaseDeviceAddress(vm, info); -- 2.53.0

2 1

[PATCH] util: Move 'virProcessLimitResourceToLabel' into same preprocessor if-block as only caller
by Peter Krempa 10 Mar '26

10 Mar '26

From: Peter Krempa <pkrempa(a)redhat.com> 'virProcessLimitResourceToLabel' is called only from 'virProcessGetLimitFromProc' but the latter has different conditions when it's compiled. In certain cases this could lead to build failures. Fixes: 90fe839f8a0 Closes: https://gitlab.com/libvirt/libvirt/-/work_items/848 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/virprocess.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/util/virprocess.c b/src/util/virprocess.c index e8120c1bdc..e06ed94b0d 100644 --- a/src/util/virprocess.c +++ b/src/util/virprocess.c @@ -743,36 +743,36 @@ virProcessPrLimit(pid_t pid G_GNUC_UNUSED, #endif #if WITH_GETRLIMIT +# if defined(__linux__) static const char* virProcessLimitResourceToLabel(int resource) { switch (resource) { -# if defined(RLIMIT_MEMLOCK) +# if defined(RLIMIT_MEMLOCK) case RLIMIT_MEMLOCK: return "Max locked memory"; -# endif /* defined(RLIMIT_MEMLOCK) */ +# endif /* defined(RLIMIT_MEMLOCK) */ -# if defined(RLIMIT_NPROC) +# if defined(RLIMIT_NPROC) case RLIMIT_NPROC: return "Max processes"; -# endif /* defined(RLIMIT_NPROC) */ +# endif /* defined(RLIMIT_NPROC) */ -# if defined(RLIMIT_NOFILE) +# if defined(RLIMIT_NOFILE) case RLIMIT_NOFILE: return "Max open files"; -# endif /* defined(RLIMIT_NOFILE) */ +# endif /* defined(RLIMIT_NOFILE) */ -# if defined(RLIMIT_CORE) +# if defined(RLIMIT_CORE) case RLIMIT_CORE: return "Max core file size"; -# endif /* defined(RLIMIT_CORE) */ +# endif /* defined(RLIMIT_CORE) */ default: return NULL; } } -# if defined(__linux__) static int virProcessGetLimitFromProc(pid_t pid, int resource, -- 2.53.0

2 1

[PATCH] qemuhotplugtest: Run "interface-hostdev" test cases only on Linux
by Michal Privoznik 09 Mar '26

09 Mar '26

From: Michal Privoznik <mprivozn(a)redhat.com> In one of my previous commits, I've introduced "interface-hostdev" attach and detach test cases to qemuhotplugtest. And they work flawlessly, on Linux. But on anything else they fail because our virpci.c module is basically just a bunch of stub functions that do nothing but report an error, rendering my changes to virpcimock futile. BTW: this is similar to what I had done in v12.1.0-rc1~199. Fixes: f9bb819fc4841dbdff801629bf58f9fd6d7d93eb Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Verified in my FreeBSD VM. tests/qemuhotplugtest.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tests/qemuhotplugtest.c b/tests/qemuhotplugtest.c index 6cb616c59b..146e9e33c1 100644 --- a/tests/qemuhotplugtest.c +++ b/tests/qemuhotplugtest.c @@ -697,10 +697,18 @@ mymain(void) DO_TEST_DETACH("ppc64", "pseries-base-live", "hostdev-pci", false, false, "device_del", QMP_DEVICE_DELETED("hostdev0") QMP_OK); +#ifdef __linux__ + /* While <interface type='hostdev'/> is nearly the same as <hostdev/>, + * there are subtle differences, e.g. checking that PCI device specified in + * <interface/> is a VF. Checks like these are done by walking sysfs which + * is limited to Linux, obviously. And while our virpcimock creates + * necessary structure, on non-Linux the virpci.c is compiled with stubs + * that do nothing but report an error. */ DO_TEST_ATTACH("x86_64", "base-live", "interface-hostdev", false, true, "device_add", QMP_OK); DO_TEST_DETACH("x86_64", "base-live", "interface-hostdev", false, false, "device_del", QMP_DEVICE_DELETED("hostdev0") QMP_OK); +#endif DO_TEST_ATTACH("x86_64", "base-live", "interface-vdpa", false, true, "query-fdsets", "{\"return\":[{\"fdset-id\":99999}]}", "add-fd", "{ \"return\": { \"fdset-id\": 1, \"fd\": 95 }}", -- 2.52.0

2 1

[PATCH] util: extend virHostCPUGetInfo() for FreeBSD
by Roman Bogorodskiy 09 Mar '26

09 Mar '26

Extend virHostCPUGetInfo() to report more data on FreeBSD, such as: - NUMA domain count - CPU core count - CPU threads per core count Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/util/virhostcpu.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 113aa6881e..7cecb4b2c8 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1014,6 +1014,22 @@ virHostCPUGetInfo(virArch hostarch G_GNUC_UNUSED, *mhz = cpu_freq / 1000000; # endif +# ifdef __FreeBSD__ +# define FILL_DATA_SYSCTL(var, sysctl, error_msg) \ + do { \ + size_t _len = sizeof(*var); \ + if (sysctlbyname(sysctl, var, &_len, NULL, 0) < 0) { \ + virReportSystemError(errno, "%s", error_msg); \ + return -1; \ + } \ + } while (0) + + FILL_DATA_SYSCTL(nodes, "vm.ndomains", _("cannot obtain NUMA domain count")); + FILL_DATA_SYSCTL(cores, "kern.smp.cores", _("cannot obtain CPU core count")); + FILL_DATA_SYSCTL(threads, "kern.smp.threads_per_core", + _("cannot obtain CPU threads per core")); +# endif /* __FreeBSD__ */ + return 0; #else /* XXX Solaris will need an impl later if they port QEMU driver */ -- 2.52.0

2 1

[PATCH 0/3] docs: bhyve documentation updates
by Roman Bogorodskiy 09 Mar '26

09 Mar '26

Roman Bogorodskiy (3): docs: bhyve: document NUMA domains configuration docs: bhyve: fix typo in version number docs: bhyve: add arm64 guest example docs/drvbhyve.rst | 64 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 63 insertions(+), 1 deletion(-) -- 2.52.0

2 4

[PATCH] qemu: processShutdownCompletedEvent: Remove inactive VM object after shutdown
by Peter Krempa 09 Mar '26

09 Mar '26

From: Peter Krempa <pkrempa(a)redhat.com> When the qemu process can't be successfully killed (e.g. when it's stuck in a long system call) libvirt creates a watch and waits for the monitor socket to go away before cleaning up the domain. The cleanup code in 'processShutdownCompletedEvent' called 'qemuProcessStop' but didn't call also 'qemuDomainRemoveInactive' which would break if a transient VM would undergo the delayed cleanup as we'd still have it's VM object around. Fixes: e62c26a20dced58ea342d9cb8f5e9164dc3bb023 Closes: https://gitlab.com/libvirt/libvirt/-/work_items/853 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9e4d0f8640..7d33477636 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -4079,6 +4079,7 @@ processShutdownCompletedEvent(virDomainObj *vm) if (virDomainObjIsActive(vm)) { qemuProcessStop(vm, VIR_DOMAIN_SHUTOFF_UNKNOWN, VIR_ASYNC_JOB_NONE, 0); + qemuDomainRemoveInactive(vm, 0, false); } qemuProcessEndStopJob(vm); -- 2.53.0

2 1

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