July 2026 - Devel - libvirt List Archives

[PATCH 0/6] virsh: Add missing TAB completers for several commands
by rsmigiel＠redhat.com 10 Jul '26

10 Jul '26

From: Radoslaw Smigielski <rsmigiel(a)redhat.com> This series adds missing virsh TAB completion callbacks for six command options: - dump --file - blockcopy --dest - detach-interface --type - domdisplay --type - domxml-from-native --format - save --file This is a small step towards closing the missing completers tracked in: https://gitlab.com/libvirt/libvirt/-/work_items/9 As of now there are 29 missing bash completers, the one fixed in this patch is first batch. As some of the patches change only one line, I would apprecate your feedback if these small one should be combined into a single patch? Radoslaw Smigielski (6): virsh: Add completer for '--file' option of 'dump' subcommand virsh: Add completer for '--dest' option of 'blockcopy' command virsh: Add completer for '--type' option of 'detach-interface' command virsh: Add completer for '--type' option of 'domdisplay' command virsh: Add completer for '--format' option of 'domxml-from-native' command virsh: Add completer for '--file' option of 'save' command tools/virsh-completer-domain.c | 49 ++++++++++++++++++++++++++++++++++ tools/virsh-completer-domain.h | 10 +++++++ tools/virsh-domain.c | 6 +++++ 3 files changed, 65 insertions(+) -- 2.54.0

2 11

Limit USB 1.0 (UHCI/OCHI) and 2.0 (EHCI) to non-virt use cases
by Daniel P. Berrangé 09 Jul '26

09 Jul '26

QEMU has implemented four generic USB controllers * UHCI - USB 1.0 only * OHCI - USB 1.0 only * EHCI - USB 2.0 only (must have UHCI companions for 1.0 compat) * XHCI - All of USB 3.0, 2.0, 1.0 in one controller We have two variants of XHCI, the generic one (hcd-xhci.c) and the NEC one (hcd-xhci-nec.c) Historically for security reports we have considered all of them in scope of virtualization, since initially with KVM the XHCI impl was not present in QEMU & thus KVM guests used UHCI/EHCI with USB tablet for a period of time All of the USB subsystem is currently orphaned, so we have no dedicated maintainer available to deal with bug reports (volunteers welcome to step up here...) While the need for USB is reduced given the availability of virtio-input, not all guests have drivers out of the box, so at least USB tablet is still interesting for KVM use cases with some modern OS. It is also not that unusual for people to need USB host device assignment with KVM virt to make various pieces of specialized hardware (security tokens, smart cards, custom dongles, etc) available directly to guests. IOW, we can't entirely exclude USB from virtualization use cases IMHO. In terms of virtualization, XHCI is the only impl that is sensible to use. UHCI/OHCI/EHCI all impose an unreasonable CPU load on any guest usage of USB. XHCI should be supported by any guest OS approx the last 15 years, which should be sufficient for virtualization use cases with OS that are not EOL by their vendor. Thus to reduce our maint burden around security bug handling, it is proposed henceforth to classify UHCI, OHCI and EHCI under the non- virtualization use case and thus be excluded from security bug triage processes. No CVEs would be assigned, bugs would be reported publically in gitlab: https://www.qemu.org/docs/master/system/security.html#non-virtualization-us… The XHCI controller (specifically the hcd-xhci.c variant) would remain as our only option for the virtualization use case, with security process applied to bugs & eligible for CVE assignment: https://www.qemu.org/docs/master/system/security.html#virtualization-use-ca… The other NEC XHCI variant (hcd-xhci-nec.c) would also be treated as non-virtualization use case, since it needlessly duplicates hcd-xhci.c impl and thus is only interesting for emulation of this specific HW variant. NB, there are no functional limitations / restrictions from this policy, it is largely just a semantic exercise. From a management application POV, however, it would strongly suggest that guests be configured with XHCI as the default choice if the user asks for USB, and in turn also imply that '-usb' not be used since that is UHCI/OHCI typically. CC'ing libvirt, though it is really a matter for virt-install/virt-manager/ openstack/kubevirt etc above libvirt to pick their defaults for USB controllers. None the less XHCI would still be in search of a maintainer to step forward and handle ongoing development and maint work. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|

5 7

[PATCH] docs: drvbhyve: document newly added pf check
by Nimish Jain 09 Jul '26

09 Jul '26

Reflects that the pf firewall check was added in virt-host-validate. Signed-off-by: Nimish Jain <unauthorizen(a)gmail.com> --- docs/drvbhyve.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/drvbhyve.rst b/docs/drvbhyve.rst index 2e5e361115..51782f8090 100644 --- a/docs/drvbhyve.rst +++ b/docs/drvbhyve.rst @@ -11,8 +11,8 @@ recommended to use the `latest supported release <https://www.freebsd.org/releases/>`__ to make sure all new features of bhyve are supported. In order to enable bhyve on your FreeBSD host, you'll need -to load the ``vmm`` kernel module. Additionally, ``if_tap`` and ``if_bridge`` -modules should be loaded for networking support. Also, :since:`since 3.2.0` the +to load the ``vmm`` kernel module. Additionally, ``if_tap``, ``if_bridge`` +and ``pf`` modules should be loaded for networking support. Also, :since:`since 3.2.0` the ``virt-host-validate(1)`` supports the bhyve host validation and could be used like this: @@ -21,6 +21,7 @@ like this: $ virt-host-validate bhyve BHYVE: Checking for vmm module : PASS BHYVE: Checking for if_tap module : PASS + BHYVE: Checking for pf module : PASS BHYVE: Checking for if_bridge module : PASS BHYVE: Checking for nmdm module : PASS $ -- 2.39.5 (Apple Git-154)

2 1

[PATCH] docs: drvnetwork: Update sample pf.conf to include NAT forwarding for FreeBSD
by Nimish Jain 09 Jul '26

09 Jul '26

This is beneficial for new users using the 'default' libvirt network configuration on FreeBSD, to get a VM up and running quickly. Also fixes a typo ('netowork') Signed-off-by: Nimish Jain <unauthorizen(a)gmail.com> --- docs/drvnetwork.rst | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/drvnetwork.rst b/docs/drvnetwork.rst index 23082310ba..881b828d5f 100644 --- a/docs/drvnetwork.rst +++ b/docs/drvnetwork.rst @@ -10,14 +10,17 @@ Platform-specific notes FreeBSD ------- -FreeBSD netowork driver uses the pf firewall. Libvirt managed pf rules +FreeBSD network driver uses the pf firewall. Libvirt managed pf rules are created within anchors. Anchors need to be configured manually by -the user. Sample ``/etc/pf.conf`` might look like: +the user. Sample ``/etc/pf.conf`` with a basic NAT configuration +might look like: :: scrub all + nat on em0 from {192.168.122.0/24} to any -> (em0) + nat-anchor "libvirt\*" anchor "libvirt\*" -- 2.39.5 (Apple Git-154)

2 1

[PATCH 0/6] qemu: Support AF_VSOCK transport for QGA communication
by Polina Vishneva 09 Jul '26

09 Jul '26

This series add support for talking to QEMU guest agent via a vsock transport. This transport is attempted when there's no ready virtio-serial channels **and** the domain has a usable vsock CID. AF_VSOCK are sockets too, so most of the virtio-serial/UNIX socket code is reused for everything except the connection lifecycle management (that is, initial connection etc.). Since QGA has no readiness notification mechanism for vsock transport, unlike for virtio-serial transport, we have to knock on the port to probe for readiness. For that, a custom backoff logic with cancellation support is implemented. Both the new virVsockConnectQuiet helper and the vsock QGA connection logic itself are covered by new tests. Polina Vishneva (6): util: Add virVsockConnectQuiet helper qemu: Extract qemuProcessResetAgent helper qemu: Add qemuDomainVsockHasGuestCid helper qemu: Support AF_VSOCK transport for QGA communication tests: Add a unit test for virVsockConnectQuiet() tests: Add a test for qemuConnectAgent() to cover the vsock path src/hypervisor/qemu_agent.c | 73 +++++---- src/hypervisor/qemu_agent.h | 9 ++ src/libvirt_private.syms | 2 + src/qemu/qemu_domain.c | 28 +++- src/qemu/qemu_domain.h | 8 + src/qemu/qemu_driver.c | 16 +- src/qemu/qemu_hotplug.c | 6 + src/qemu/qemu_process.c | 305 +++++++++++++++++++++++++++++++---- src/qemu/qemu_process.h | 2 + src/util/virvsock.c | 71 +++++++- src/util/virvsock.h | 10 ++ tests/meson.build | 3 + tests/qemuagenttest.c | 43 ++++- tests/qemumonitortestutils.c | 119 +++++++++++++- tests/qemumonitortestutils.h | 4 + tests/qemuvsockagentmock.c | 65 ++++++++ tests/virvsockmock.c | 143 ++++++++++++++++ tests/virvsocktest.c | 133 +++++++++++++++ 18 files changed, 963 insertions(+), 77 deletions(-) create mode 100644 tests/qemuvsockagentmock.c create mode 100644 tests/virvsockmock.c create mode 100644 tests/virvsocktest.c -- 2.54.0

1 6

[PATCH v2] vbox: fix memory leak in vboxStartMachine()
by Elizaveta Tereshkina 09 Jul '26

09 Jul '26

vboxStartMachine() allocates sdlDisplay via g_strdup() and doesn't free it. Replace VIR_FREE calls in the function with g_autofree macro. Fixes: 3f4f0ef47d (vbox: Fix starting domains) Signed-off-by: Elizaveta Tereshkina <teryoshkina.ea(a)gmail.com> --- src/vbox/vbox_common.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/vbox/vbox_common.c b/src/vbox/vbox_common.c index 65ae9cc651..63401613d5 100644 --- a/src/vbox/vbox_common.c +++ b/src/vbox/vbox_common.c @@ -2162,8 +2162,8 @@ vboxStartMachine(virDomainPtr dom, int maxDomID, IMachine *machine) int vrdpPresent = 0; int sdlPresent = 0; int guiPresent = 0; - char *guiDisplay = NULL; - char *sdlDisplay = NULL; + g_autofree char *guiDisplay = NULL; + g_autofree char *sdlDisplay = NULL; PRUnichar *keyTypeUtf16 = NULL; PRUnichar *valueTypeUtf16 = NULL; char *valueTypeUtf8 = NULL; @@ -2233,7 +2233,7 @@ vboxStartMachine(virDomainPtr dom, int maxDomID, IMachine *machine) if (guiPresent || sdlPresent) { const char *display = NULL; const char *sessType = NULL; - char *displayutf8; + g_autofree char *displayutf8 = NULL; if (guiPresent) { sessType = "gui"; @@ -2250,8 +2250,6 @@ vboxStartMachine(virDomainPtr dom, int maxDomID, IMachine *machine) displayutf8 = g_strdup_printf("DISPLAY=%s", display); VBOX_UTF8_TO_UTF16(displayutf8, &env); - VIR_FREE(displayutf8); - VIR_FREE(guiDisplay); VBOX_UTF8_TO_UTF16(sessType, &sessionType); } else if (vrdpPresent) { -- 2.39.2

1 0

[PATCH 0/2] virt-host-validate-bhyve: Improve checks
by Nimish Jain 08 Jul '26

08 Jul '26

Nimish Jain (2): replace if_tap check with if_tuntap check add pf check tools/virt-host-validate-bhyve.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) -- 2.39.5 (Apple Git-154)

2 3

RFC: GitLab confidential issues for security disclosures ?
by Daniel P. Berrangé 08 Jul '26

08 Jul '26

The QEMU project has just changed to use GitLab confidential issues for security disclosures. https://www.qemu.org/contribute/security-process/ While libvirt isn't (yet) suffering the same massive AI powered bug tsunami, I'm not seeing an especially compelling reason to continue using email for security disclosures with such limited need-to-know practices. While using GitLab theoretically exposes us to greater risk of exposure via the GitLab's own staff / infra compromise, in practice they likely do a better job securing their infra than we do for our mailman install. Submissions are also guaranteed TLS protection which we can't so confidently assume for email. We don't tend to apply any long embargo times. Our maintainers are all trusted with commit access to libvirt.git, so from a trust POV I feel it acceptable to have scurity disclosures visible to all of them instead of restricted to a handful of maintainers. The security list has a handful of people from the distro present who in theory can watch it for early access to disclosures. I'm not sure if that makes a difference in practice though, especially with all the distros suffering an AI bug tsunami leading to greatly extended fix times. IOW, overall a lighter weight process using GitLab confidential issues feels like it should be sufficient for libvirt too. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|

2 2

[PATCH v7 00/35] monitor: turn QMP and HMP into QOM objects
by Daniel P. Berrangé 07 Jul '26

07 Jul '26

Conceptually -object and object_add/object_del should be sufficient for essentially all QEMU configuration....if only we ported all our internal custom backends/devices/etc to QOM. That is of course a big job which is why it hasn't happened. This series started with the premise that the monitor is one of the easier areas to convert since we have no more than three classes, a common base, and QMP and HMP subclasses[1]. So why not give it a go and thus unlock the ability to dynamically create/delete monitors in QMP/HMP. This series does the conversion in a great many small steps to better understand the implications at each stage. The high level outcome of this series is * HMP and QMP monitors are QOM objects, 'monitor-hmp' and 'monitor-qmp' respectively * Both can be cold plugged and hot plugged. QMP only, can also be hot unplugged. * '-mon' is obsolete, deprecated and replaced by '-object', but -monitor, -qmp and kept as high level syntax sugar * QMP gains a concept of "close-action" which makes it possible to mark a monitor for auto-delete. The monitor hot-unplug code and the qtest and functional testing code is heavily derived from a series sent by Christian Brauner which proposed new monitor_add/monitor_del commands: https://lists.nongnu.org/archive/html/qemu-devel/2026-04/msg01349.html I left Christian's authorship & SoB on the patches which were derived from his code, though the code has been refactored quite a bit in places, so bugs are quite possibly my own. Note that Christian's series allowed the use of "monitor_del" commands against the current monitor session. ie a client could delete the very monitor it was using. This is an awkward concept as it needs special casing to delay the deletion to happen in the background, such that that the QMP response to 'monitor_del' could still be sent back. This also left the chardev was orphaned as there's no way to run 'chardev_dev' in that usage pattern. To provide an alternative mechanism to address the same use case, this series introduces the 'close-action' concept mentioned above, that allows hotplugging a monitor to service a specific task, with the monitor being purged when the script closes its connection. This avoids the special casing that an explicit "self deletion" paradigm required. While supporting hotplug of HMP was trivial, I didn't do any work to think about hotunplug of HMP, since IMHO it is of limited value given HMP's typical use cases. [1] ~~~ we did all this not because it was easy, but because we thought it would be easy ~~~ Changed in v7: - Split Chardev -> const char *chardev_id change into separate patch from QOM property addition - Copy editting of qemu-options docs - Updating of commit messages with improved wording - Remove redundant ERRP_GUARD - Improve error message wording when rejecting delete requests - Don't hardcode "gdbchrdev0" ID, allow default logic Changed in v6: - Present "ID" from QemuOpts to use for the QOM object - Use 'compat_monitorNNN' as ID if QemuOpts lacks an ID, for compat with -monitor/-qmp arg naming - Mark the Monitor class abstract when first defined - Tweaks to formatting of QAPI docs - Expand CLI docs to describe relation between -monitor and -qmp and -object. - Present object ID in error messages for prepare_delete callback - Drop API which dupes object_get_canonical_path_component - Dropped R-B on patches 01, 05, 34 Changed in v5: - Address another race when looking up monitor by ID - Refer to "line editting" when talking about HMP readline feature - Misc typos - Fix mis-placed setting of 'delete_pending' - Add test case to validate reconnecting to QMP Changed in v4: - Hold reference into BH to avoid race with auto-delete Changed in v3: - Removed unused 'dead' struct field - Make use of 'setup_pending' struct field across BH - Add missing free of chardev_id - Add missnig ERRP_GUARD in monitor_new_qmp - Misc docs typos / rephrasing - Moved docs patch to the end - Fixed docs about the default QOM ID naming for legacy monitor syntax - Fixed random sleep time calculation in tests Christian Brauner (6): monitor: convert from oneshot BH to persistent BH monitor: reject attempts to delete the current monitor monitor: protect qemu_chr_fe_accept_input with monitor lock monitor: implement support for deleting QMP objects tests/qtest: add tests for dynamic monitor add/remove tests/functional: add e2e test for dynamic QMP monitor hotplug Daniel P. Berrangé (29): qom: replace 'can_be_deleted' with 'prepare_delete' monitor: replace 'common' with 'parent_obj' in MonitorHMP monitor: replace 'common' with 'parent_obj' in MonitorQMP monitor: rename monitor_init* to monitor_new* monitor: minimal conversion of monitors to QOM monitor: pass chardev ID into monitor constructor instead of object monitor: add 'chardev' property to Monitor base class monitor: add 'readline' property to HMP Monitor class monitor: add 'pretty' property to QMP Monitor class monitor: remove 'skip_flush' field monitor: move monitor_data_(init|destroy) into QOM init/finalize monitor: use class methods for monitor_vprintf monitor: use class methods for monitor_qapi_event_emit monitor: use class methods for monitor_accept_input monitor: use class method for I/O thread request monitor: use dynamic cast in monitor_qmp_requests_pop_any_with_lock util: use dynamic cast in error vreport monitor: drop unused monitor_cur_is_qmp monitor: use dynamic cast in QMP commands monitor: use dynamic cast in monitor_is_hmp_non_interactive monitor: drop unused monitor_is_qmp method monitor: eliminate monitor_is_hmp_non_interactive method monitor: implement "user creatable" interface for adding monitors tests/functional: add a stress test for monitor hot unplug qom: add trace events for user creatable create/delete APIs monitor: add support for auto-deleting monitors upon close tests: switch from -mon to -object monitor-qmp qemu-options: document new monitor-hmp and monitor-qmp objects docs: mark '-mon' as deprecated in favour of -object MAINTAINERS | 1 + backends/cryptodev.c | 12 +- backends/hostmem.c | 7 +- backends/iommufd.c | 11 +- block/throttle-groups.c | 12 +- chardev/char.c | 3 +- docs/about/deprecated.rst | 10 + docs/devel/writing-monitor-commands.rst | 4 +- docs/system/arm/xenpvh.rst | 4 +- docs/system/i386/xen.rst | 3 +- docs/system/i386/xenpvh.rst | 4 +- event-loop-base.c | 8 +- gdbstub/system.c | 2 +- include/monitor/monitor.h | 26 +- include/qom/object_interfaces.h | 26 +- include/system/event-loop-base.h | 2 +- migration/migration-hmp-cmds.c | 5 +- monitor/hmp-cmds.c | 7 +- monitor/hmp.c | 181 ++++++++-- monitor/monitor-internal.h | 73 ++-- monitor/monitor.c | 271 ++++++++------- monitor/qmp-cmds-control.c | 12 +- monitor/qmp-cmds.c | 14 +- monitor/qmp.c | 323 +++++++++++++++--- net/can/can_core.c | 6 +- python/qemu/machine/machine.py | 4 +- qapi/qom.json | 63 ++++ qemu-options.hx | 65 +++- qom/object_interfaces.c | 20 +- qom/trace-events | 5 + storage-daemon/qemu-storage-daemon.c | 2 +- stubs/monitor-core.c | 5 - stubs/monitor-internal.c | 4 +- system/vl.c | 19 +- tests/functional/generic/meson.build | 1 + .../generic/test_monitor_hotplug.py | 305 +++++++++++++++++ tests/qemu-iotests/245 | 4 +- tests/qtest/libqtest.c | 2 +- tests/qtest/qmp-test.c | 174 ++++++++++ tests/unit/test-util-sockets.c | 1 - tools/qemu-vnc/stubs.c | 5 - ui/ui-hmp-cmds.c | 2 +- util/error-report.c | 13 +- util/main-loop.c | 6 +- 44 files changed, 1395 insertions(+), 332 deletions(-) create mode 100755 tests/functional/generic/test_monitor_hotplug.py -- 2.55.0

3 46

[PATCH] node_device_udev: fix deadlock joining udev thread under lock
by Christopher Johannimloh 07 Jul '26

07 Jul '26

From: Christopher Johannimloh <C.Johannimloh(a)beckhoff.com> In our CI environment we install and purge all packages we use during a single test. During testing of libvirtd we observed intermittent hangs during apt purge of the libvirt packages. After investigation I found out that the hang is caused by a deadlock in nodeStateShutdownWait() which joins the udev thread while holding the lock of the udevEventData object. The udev thread needs the same lock to make progress and exit, so if the shutdown thread wins the race for the lock the join can never complete and the shutdown thread will later be killed by the 30s timeout [1]. [1] https://gitlab.com/libvirt/libvirt/-/blob/364977b94a776230037aa159be55bb95f… Fixes: e89d39f5b8f30f0b3284ed2bd71cee1a8a3d707d Signed-off-by: Christopher Johannimloh <C.Johannimloh(a)beckhoff.com> --- src/node_device/node_device_udev.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 104433fb88..28c8f00361 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -2482,10 +2482,8 @@ nodeStateShutdownWait(void) if (!priv) return 0; - VIR_WITH_OBJECT_LOCK_GUARD(priv) { - if (priv->udevThread) - virThreadJoin(priv->udevThread); - } + if (priv->udevThread) + virThreadJoin(priv->udevThread); if (priv->workerPool) virThreadPoolDrain(priv->workerPool); -- 2.47.3 This email contains confidential information. If you have received it in error, you must not read, use, copy or pass on this e-mail or its attachments. If you have received the e-mail in error, please inform me immediately by reply e-mail and then delete this e-mail from your system. Thank you Diese E-Mail enthält vertrauliche Informationen. Sollten Sie sie irrtümlich erhalten haben, dürfen Sie diese E-Mail oder ihre Anhänge nicht lesen, verwenden, kopieren oder weitergeben. Sollten Sie die Mail versehentlich erhalten haben, teilen Sie mir dies bitte umgehend per Antwort-E-Mail mit und löschen Sie diese E-Mail dann aus Ihrem System. Vielen Dank Beckhoff Automation GmbH & Co. KG Managing Director: Dipl. Phys. Hans Beckhoff Registered office: Verl, Germany Register court: Guetersloh HRA 7075 DisclaimerID:x9d5u140

1 0