- Devel - libvirt List Archives

[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

[PATCH] systemtap: Fix probe definition for 'rpc_tls_context_new'
by Peter Krempa 10 Mar '26

10 Mar '26

From: Peter Krempa <pkrempa(a)redhat.com> Commit d249170bf609d2c modified the arguments of 'virNetTLSContextNew' which has a systemtap probe point defined. This in turn meant that the probe point needed to be modified too. Unfortunately the systemtap generator doesn't handle double pointers correctly and in fact systemtap doesn't even seem to have a possibility to fetch a list of strings from userspace natively. This meant that an invalid probe definition was generated: 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 declare the 'cert' and 'keys' parameters as 'void *', we can't really do anything else as string lists aren't supported, which will make our generator generate correct code once again. Resolves: https://issues.redhat.com/browse/RHEL-153832 Fixes: d249170bf609d2cb89c36477b0f9ca0908f25985 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/libvirt_probes.d | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libvirt_probes.d b/src/libvirt_probes.d index d9e75d9797..16d1decf46 100644 --- a/src/libvirt_probes.d +++ b/src/libvirt_probes.d @@ -54,7 +54,7 @@ provider libvirt { # file: src/rpc/virnettlscontext.c # prefix: rpc probe rpc_tls_context_new(void *ctxt, const char *cacert, const char *cacrl, - const char **cert, const char **keys, + void *cert, void *keys, int sanityCheckCert, int requireValidCert, int isServer); probe rpc_tls_context_dispose(void *ctxt); probe rpc_tls_context_session_allow(void *ctxt, void *sess, const char *dname); -- 2.53.0

2 4

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