June 2025 - Devel - libvirt List Archives

pci-hole64-size on q35 questions
by mitchell.augustin＠canonical.com 01 Jul '25

01 Jul '25

Hi, I'm trying to get a better understanding of how libvirt VMs interact with the default QEMU setting for pci-hole64-size on q35 hosts, to assess why my libvirt VMs behave differently from a similarly configured lxd VM. As I understand, both libvirt and lxd are using qemu q35 VMs under the hood, and both are inheriting their pci-hole64-size from qemu's default setting (correct me if that's wrong), but in my tests, I'm getting different behavior from them. I know lxd is probably out of scope from the libvirt project perspective, so consider this more of a libvirt question w/ some added lxd context. All of this is on a DGX B200 host, which contains large (~180GB VRAM) GPUs. With libvirt/virt-install, I created a q35 virtual machine with CPU host passthrough and 1 or more GPUs passed-through via --host-device. Without additional modifications, this works as expected, and I can initialize the GPU driver in the VM and run nvidia-smi. With lxd (which creates a q35 virtual machine with CPU host passthrough by default), I attached 1 GPU via "lxc config device add passthroughtest gpu gpu pci=1b:00.0". On that machine, the pci-hole64-size is too small by default, since I see these in my dmesg: [ 1.099110] pci 0000:00:01.5: bridge window [mem size 0x6000000000 64bit pref]: can't assign; no space [ 1.120274] pci 0000:00:01.5: bridge window [mem size 0x6000000000 64bit pref]: can't assign; no space [ 1.183281] pci 0000:06:00.0: BAR 2 [mem size 0x4000000000 64bit pref]: can't assign; no space [ 1.186320] pci 0000:06:00.0: BAR 0 [mem size 0x04000000 64bit pref]: can't assign; no space [ 1.189340] pci 0000:06:00.0: BAR 4 [mem size 0x02000000 64bit pref]: can't assign; no space and I cannot initialize the GPU driver since the BARs weren't mapped correctly. When I apply a larger hole size to my lxd VM via `lxc config set passthroughtest raw.qemu=' -global q35-pcihost.pci-hole64-size=8192G'`, I don't see any "can't assign; no space" messages, and the driver works as expected. My question about libvirt is - where (if at all) does libvirt interact with qemu's pci-hole64-size value? If libvirt does not automatically do something functionally similar to changing the hole size like I need to do above for lxd, and is in fact just using a qemu default value, is there some other related interaction happening in libvirt that might explain why my libvirt VMs don't require a manual change to pci-hole64-size, despite the fact that the relevant parts of the underlying qemu machine should be the same?

2 1

[libvirt PATCH] NEWS: document new AMD IOMMU device
by Ján Tomko 30 Jun '25

30 Jun '25

From: Ján Tomko <jtomko(a)redhat.com> Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- Applies on top of Peter's NEWS patch NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 3ffdceda81..fd2d68a600 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -45,6 +45,12 @@ v11.5.0 (unreleased) with CA certificate(s) that will be used for remote peer certificate validation. + * qemu: add support for AMD IOMMU device + + The ``amd`` model for the ``<iommu>`` device is now supported. + New attributes ``passtrhough`` and ``xtsup`` are also supported for this + model. + * **Improvements** * Include supported console types in domain capabilities -- 2.49.0

2 1

Re: [PATCH v2 09/10] net: Add passt network backend
by Markus Armbruster 30 Jun '25

30 Jun '25

Laurent Vivier <lvivier(a)redhat.com> writes: > On 24/06/2025 10:16, Markus Armbruster wrote: >> Laurent Vivier <lvivier(a)redhat.com> writes: >> >>> This commit introduces support for passt as a new network backend. >>> passt is an unprivileged, user-mode networking solution that provides >>> connectivity for virtual machines by launching an external helper process. >>> >>> The implementation reuses the generic stream data handling logic. It >>> launches the passt binary using GSubprocess, passing it a file >>> descriptor from a socketpair() for communication. QEMU connects to >>> the other end of the socket pair to establish the network data stream. >>> >>> The PID of the passt daemon is tracked via a temporary file to >>> ensure it is terminated when QEMU exits. >>> >>> Signed-off-by: Laurent Vivier <lvivier(a)redhat.com> >> >> [...] >> >>> diff --git a/qapi/net.json b/qapi/net.json >>> index 97ea1839813b..76d7654414f7 100644 >>> --- a/qapi/net.json >>> +++ b/qapi/net.json >>> @@ -112,6 +112,125 @@ >>> 'data': { >>> 'str': 'str' } } >>> >>> +## >>> +# @NetDevPasstOptions: >>> +# >>> +# Unprivileged user-mode network connectivity using passt >>> +# >>> +# @path: path to passt binary >> >> I'd prefer a more descriptive name. >> >> Elsewhere in this file, we refer to programs like this: >> >> # @script: script to initialize the interface >> # >> # @downscript: script to shut down the interface >> >> passt isn't a script, of course. >> >> I don't know, perhaps >> >> # @passt-filename: the passt program to run. >> >> or even >> >> # @passt: Filename of the passt program to run. >> >>> +# >>> +# @quiet: don't print informational messages >> >> What does the printing? A peek at the code I snipped suggests this flag >> is passed to the passt binary as --quiet. Correct? >> >>> +# >>> +# @debug: be verbose >>> +# >>> +# @trace: extra verbose >> >> Likewise for these two. >> >>> +# >>> +# @vhost-user: enable vhost-user [...] >>> +# @udp-ports: UDP ports to forward >> >> Is there anything in this struct that configures qemu-system-FOO itself, >> i.e. isn't just passed to passt? >> > > Yes, all parameters are just passed to passt. > > Do you think it's better not to add all these parameters to netdev backend but only one > generic containing the passt command line parameters? I'm not sure. Thoughts from libvirt's perspective?

4 4

[PATCH v3] remote/stream-event: Fix a memory leak in remoteStreamCallbackFree()
by liu.xuemei1＠zte.com.cn 30 Jun '25

30 Jun '25

From: Liu Song <liu.song13(a)zte.com.cn> The ff callback is never called in remoteStreamCallbackFree() because cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'. The leak can be reproduced by attaching and detaching to the console of an VM using `virsh console`. ASAN reports the leak stack as: Direct leak of 288 byte(s) in 1 object(s) allocated from: #0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7) #1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0) #2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3) #3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf) #4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877) #5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620) #6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252 #7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274 #8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369 #9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427 Signed-off-by: Liu Song <liu.song13(a)zte.com.cn> --- Changes in v3: - Remove the second reference to 'client', and unref 'client' in error path. src/remote/remote_daemon_stream.c | 7 ++++--- src/remote/remote_driver.c | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 453728a66b..b6099e3bc7 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -437,12 +437,13 @@ int daemonAddClientStream(virNetServerClient *client, return -1; } + virObjectRef(client); if (virStreamEventAddCallback(stream->st, 0, daemonStreamEvent, client, - virObjectUnref) < 0) + virObjectUnref) < 0) { + virObjectUnref(client); return -1; - - virObjectRef(client); + } if ((stream->filterID = virNetServerClientAddFilter(client, daemonStreamFilter, diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 2690c05267..9ac13469e9 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque) { struct remoteStreamCallbackData *cbdata = opaque; - if (!cbdata->cb && cbdata->ff) + if (cbdata->ff) (cbdata->ff)(cbdata->opaque); virObjectUnref(cbdata->st); -- 2.27.0

1 0

[PATCH] NEWS: Mention 'virsh await' and proper emulation of USB cdroms
by Peter Krempa 30 Jun '25

30 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 089224cbe3..3ffdceda81 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -58,6 +58,12 @@ v11.5.0 (unreleased) </enum> </console> + * virsh: Add waiting for domain state via ``virsh await`` + + The new helper command ``virsh await`` simplifies waiting on domain state + which is normally announced via events. Currently two waiting conditions are + implemented: ``domain-inactive``, and ``guest-agent-available``. + * **Bug fixes** * qemu: Be more forgiving when acquiring QUERY job when formatting domain XML @@ -72,6 +78,12 @@ v11.5.0 (unreleased) shared filesystem (via the ``shared_filesystems`` option in ``qemu.conf`` would not be properly detected as being on a shared filesystem. + * qemu: Properly emulate USB cdrom device + + CD-ROM devices on USB bus are now properly emulated as such which was not + the case since libvirt switched to the modern qemu commandline sytnax for + storage backends. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

[PATCH] NEWS: Mention shared filesystem detection fix
by Jiri Denemark 30 Jun '25

30 Jun '25

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index ee4e9a022e..089224cbe3 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -66,6 +66,12 @@ v11.5.0 (unreleased) domain XML acquires QUERY job. But this caused a regression when the API might timeout for incoming migration. This is now fixed. + * qemu: Fix shared filesystem detection on nonexistent paths + + Since ``libvirt-11.1.0`` nonexistent paths within directories marked as + shared filesystem (via the ``shared_filesystems`` option in ``qemu.conf`` + would not be properly detected as being on a shared filesystem. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 30 Jun '25

30 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 184df16547..ee4e9a022e 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -60,6 +60,12 @@ v11.5.0 (unreleased) * **Bug fixes** + * qemu: Be more forgiving when acquiring QUERY job when formatting domain XML + + Since ``libvirt-11.0.0`` the ``virDomainGetXMLDesc()`` API used to format + domain XML acquires QUERY job. But this caused a regression when the API + might timeout for incoming migration. This is now fixed. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

Re: [PATCH v3 2/2] virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks
by Michal Prívozník 30 Jun '25

30 Jun '25

On 6/25/25 18:49, Tim Small wrote: > > > On 09/06/2025 13:51, Michal Prívozník wrote: > >> But this new IPC got me thinking - the XML we're parsing here in the aa >> helper is formatted by libvirtd who already know the actual type of each >> net. But looking into the code - this is lost when the daemon talks to >> the helper. I'm not on an AppArmor machine right now, so can you please >> check whether the following change (applied on the top of this very >> patch) works? It would save us from those IPCs. > > Thanks Michal. The additional patches which you posted (below) did not > work in isolation, but with an additional change to the src/qemu/ > qemu_process.c to ensure that the network is resolved before the > apparmor helper is called, it works. > > I've updated my branch and tested, and will post the updated patch to > the mailing list, but before I do-so... > > What would you like me to do with regard to the changes with you proposed? > > . Post with credit in the patch commentary. > . Post with credit in the commit message. If you want, then you can put Suggested-by: Michal Privoznik <mprivozn(a)redhat.com> line just above your SoB line. Thanks! > . Something else? > > Thanks for the tip! No problem. Introducing new RPC call always sets my alarm off :-D Michal

1 0

Entering freeze for libvirt-11.5.0
by Jiri Denemark 27 Jun '25

27 Jun '25

I have just tagged v11.5.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Jirka

2 1

[PATCH v4 0/8] qemu: acpi-generic-initiator support
by Andrea Righi 27 Jun '25

27 Jun '25

= Overview = This patch set introduces support for acpi-generic-initiator devices, supported by QEMU [1]. The acpi-generic-initiator object is required to support Multi-Instance GPU (MIG) configurations on NVIDIA GPUs [2]. MIG enables partitioning of GPU resources into multiple isolated instances, each requiring a dedicated NUMA node definition. = Implementation = This patch set implements the libvirt counterpart to the QEMU feature, enabling users to configure acpi-generic-initiator objects within libvirt domain XML. This includes: - adding XML syntax to define acpi-generic-initiator objects, - resolving the acpi-generic-initiator definitions into the proper QEMU command-line arguments, - ensuring compatibility with existing NUMA configuration. = Example = - Domain XML: ``` ... <cpu mode='host-passthrough' check='none'> <numa> <cell id='0' cpus='0-15' memory='8388608' unit='KiB'/> <cell id='1' memory='0' unit='KiB'/> <cell id='2' memory='0' unit='KiB'/> <cell id='3' memory='0' unit='KiB'/> <cell id='4' memory='0' unit='KiB'/> <cell id='5' memory='0' unit='KiB'/> <cell id='6' memory='0' unit='KiB'/> <cell id='7' memory='0' unit='KiB'/> <cell id='8' memory='0' unit='KiB'/> </numa> </cpu> ... <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>1</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>2</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>3</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>4</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>5</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>6</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>7</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>8</numa-node> </acpi-generic-initiator> </devices> ``` - Generated QEMU command line options: ``` ... /usr/bin/qemu-system-aarch64 \ ... -object '{"qom-type":"memory-backend-ram","id":"ram-node0","size":8589934592}' \ -numa node,nodeid=0,cpus=0-15,memdev=ram-node0 \ -numa node,nodeid=1 \ -numa node,nodeid=2 \ -numa node,nodeid=3 \ -numa node,nodeid=4 \ -numa node,nodeid=5 \ -numa node,nodeid=6 \ -numa node,nodeid=7 \ -numa node,nodeid=8 \ ... -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}' ... -object acpi-generic-initiator,id=gi0,pci-dev=hostdev0,node=1 \ -object acpi-generic-initiator,id=gi1,pci-dev=hostdev0,node=2 \ -object acpi-generic-initiator,id=gi2,pci-dev=hostdev0,node=3 \ -object acpi-generic-initiator,id=gi3,pci-dev=hostdev0,node=4 \ -object acpi-generic-initiator,id=gi4,pci-dev=hostdev0,node=5 \ -object acpi-generic-initiator,id=gi5,pci-dev=hostdev0,node=6 \ -object acpi-generic-initiator,id=gi6,pci-dev=hostdev0,node=7 \ -object acpi-generic-initiator,id=gi7,pci-dev=hostdev0,node=8 ``` = References = [1] https://lore.kernel.org/all/20231225045603.7654-2-ankita@nvidia.com/ [2] https://www.nvidia.com/en-in/technologies/multi-instance-gpu/ This patchset is also available in the following git branch: https://github.com/arighi/libvirt.git acpi-generic-initiator-v4 ChangeLog v3 -> v4: - add acpi-generic-initiator documentation - refactor virDomainAcpiInitiatorDef to use info->alias and drop the name attribute - auto-generate alias for the acpi-generic-initiator devices via qemuAssignDeviceAliases() - use g_autoptr() when possible - add a new entry to NEWS.rst ChangeLog v2 -> v3: - replaced <text/> with proper types in the XML schema - avoid mixing g_free() and VIR_FREE() - use virXMLPropString() instead of looping all XML nodes - report proper errors with virReportError() - use virBufferEscapeString() to process strings passed by the user - fix broken formatting of function headers - misc coding style fixes ChangeLog v1 -> v2: - split parser and driver changes in separate patches - introduce a new qemu capability flag - introduce test in qemuxmlconftest Andrea Righi (8): schema: Introduce acpi-generic-initiator definition conf: Introduce acpi-generic-initiator device qemu: Allow to define NUMA nodes without memory or CPUs assigned qemu: capabilies: Introduce QEMU_CAPS_ACPI_GENERIC_INITIATOR qemu: Support acpi-generic-initiator qemu: Add test case for acpi-generic-initiator docs: Document acpi-generic-initiator device NEWS: Mention new acpi-generic-initiator device NEWS.rst | 8 ++ docs/formatdomain.rst | 36 ++++++ src/ch/ch_domain.c | 1 + src/conf/domain_conf.c | 138 +++++++++++++++++++++ src/conf/domain_conf.h | 14 +++ src/conf/domain_postparse.c | 1 + src/conf/domain_validate.c | 37 ++++++ src/conf/numa_conf.c | 3 + src/conf/schemas/domaincommon.rng | 14 +++ src/conf/virconftypes.h | 2 + src/hyperv/hyperv_driver.c | 1 + src/libxl/libxl_driver.c | 6 + src/lxc/lxc_driver.c | 6 + src/qemu/qemu_alias.c | 11 ++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 49 ++++++-- src/qemu/qemu_domain.c | 2 + src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_driver.c | 3 + src/qemu/qemu_hotplug.c | 5 + src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 1 + src/test/test_driver.c | 4 + tests/qemucapabilitiesdata/caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 1 + .../acpi-generic-initiator.x86_64-latest.args | 55 ++++++++ .../acpi-generic-initiator.x86_64-latest.xml | 94 ++++++++++++++ tests/qemuxmlconfdata/acpi-generic-initiator.xml | 94 ++++++++++++++ tests/qemuxmlconftest.c | 1 + 37 files changed, 596 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.xml

2 14