February 2026 - Devel - libvirt List Archives

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 10 Apr '26

10 Apr '26

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

2 1

[PATCH] qemu: migration: Call hook script on source host at migration start
by Guy Godfroy 07 Apr '26

07 Apr '26

Currently, the qemu hook script with the "migrate" operation is only called on the destination host at the beginning of incoming migration. This makes it impossible for the source host to prepare for migration, for example to change storage locks from exclusive to shared mode when using shared LVM storage with lvmlockd. Add a hook call on the source host at the beginning of outgoing migration. The hook is called with "source" as the extra argument to distinguish it from the destination hook which uses "-". The same change is also applied to the libxl driver for consistency. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/37 Signed-off-by: Guy Godfroy <guy.godfroy(a)gugod.fr> --- docs/hooks.rst | 36 ++++++++++++++++++++++++++++++++---- src/libxl/libxl_migration.c | 17 +++++++++++++++++ src/qemu/qemu_migration.c | 17 +++++++++++++++++ 3 files changed, 66 insertions(+), 4 deletions(-) diff --git a/docs/hooks.rst b/docs/hooks.rst index e1745b8cc7..4c7cac56ba 100644 --- a/docs/hooks.rst +++ b/docs/hooks.rst @@ -244,7 +244,7 @@ operation. There is no specific operation to indicate a "restart" is occurring. - :since:`Since 0.9.11`, the qemu hook script is also called at the beginning - of incoming migration. It is called as: + of incoming migration on the **destination** host. It is called as: :: @@ -257,6 +257,18 @@ operation. There is no specific operation to indicate a "restart" is occurring. is not valid, incoming migration will be canceled. This hook may be used, e.g., to change location of disk images for incoming domains. +- :since:`Since 12.1.0`, the qemu hook script is also called at the beginning + of outgoing migration on the **source** host. It is called as: + + :: + + /etc/libvirt/hooks/qemu guest_name migrate begin source + + with domain XML sent to standard input of the script. Unlike the destination + hook, this script does not act as a filter and any output is ignored. If the + script returns failure, the migration will be canceled. This hook may be used, + e.g., to change storage lock mode from exclusive to shared before migration. + - :since:`Since 1.2.9`, the qemu hook script is also called when restoring a saved image either via the API or automatically when restoring a managed save machine. It is called as: @@ -417,7 +429,7 @@ operation. There is no specific operation to indicate a "restart" is occurring. /etc/libvirt/hooks/libxl guest_name release end - - :since:`Since 2.1.0`, the libxl hook script is also called at the beginning - of incoming migration. It is called as: + of incoming migration on the **destination** host. It is called as: :: @@ -430,6 +442,18 @@ operation. There is no specific operation to indicate a "restart" is occurring. is not valid, incoming migration will be canceled. This hook may be used, e.g., to change location of disk images for incoming domains. +- :since:`Since 12.1.0`, the libxl hook script is also called at the beginning + of outgoing migration on the **source** host. It is called as: + + :: + + /etc/libvirt/hooks/libxl guest_name migrate begin source + + with domain XML sent to standard input of the script. Unlike the destination + hook, this script does not act as a filter and any output is ignored. If the + script returns failure, the migration will be canceled. This hook may be used, + e.g., to change storage lock mode from exclusive to shared before migration. + - :since:`Since 6.5.0`, you can also place several hook scripts in the directory ``/etc/libvirt/hooks/libxl.d/``. They are executed in alphabetical order after main script. In this case each script also acts as filter and can @@ -566,10 +590,14 @@ Migration of a QEMU guest involves running hook scripts on both the source and destination hosts: #. At the beginning of the migration, the *qemu* hook script on the - **destination** host is executed with the "migrate" operation. + **source** host is executed with the "migrate" operation and "source" + as the extra argument (:since:`since 12.1.0`). This allows the source + host to prepare for migration, e.g., changing storage locks. +#. Then, the *qemu* hook script on the **destination** host is executed + with the "migrate" operation. #. Before QEMU process is spawned, the two operations ("prepare" and "start") called for domain start are executed on **destination** host. -#. If both of these hook script executions exit successfully (exit status 0), +#. If all of these hook script executions exit successfully (exit status 0), the migration continues. Any other exit code indicates failure, and the migration is aborted. #. The QEMU guest is then migrated to the destination host. diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c index f5dee7627b..76f3c7ceb7 100644 --- a/src/libxl/libxl_migration.c +++ b/src/libxl/libxl_migration.c @@ -411,6 +411,23 @@ libxlDomainMigrationSrcBegin(virConnectPtr conn, if (!libxlDomainMigrationIsAllowed(def)) goto endjob; + /* Call hook to allow source host to prepare for migration */ + if (virHookPresent(VIR_HOOK_DRIVER_LIBXL)) { + g_autofree char *hookxml = NULL; + int hookret; + + if (!(hookxml = virDomainDefFormat(def, driver->xmlopt, + VIR_DOMAIN_DEF_FORMAT_SECURE))) + goto endjob; + + hookret = virHookCall(VIR_HOOK_DRIVER_LIBXL, def->name, + VIR_HOOK_LIBXL_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN, + "source", hookxml, NULL); + + if (hookret < 0) + goto endjob; + } + xml = virDomainDefFormat(def, driver->xmlopt, VIR_DOMAIN_DEF_FORMAT_SECURE); /* Valid xml means success! EndJob in the confirm phase */ if (xml) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6dd022163b..60e370319c 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2791,6 +2791,23 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver, if (!qemuMigrationSrcIsAllowed(vm, true, vm->job->asyncJob, flags)) return NULL; + /* Call hook to allow source host to prepare for migration */ + if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { + g_autofree char *xml = NULL; + int hookret; + + if (!(xml = qemuDomainDefFormatLive(driver, priv->qemuCaps, vm->def, + priv->origCPU, false, true))) + return NULL; + + hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, + VIR_HOOK_QEMU_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN, + "source", xml, NULL); + + if (hookret < 0) + return NULL; + } + if (!(flags & (VIR_MIGRATE_UNSAFE | VIR_MIGRATE_OFFLINE)) && !qemuMigrationSrcIsSafe(vm, migrate_disks, flags)) return NULL; -- 2.34.1

4 18

[PULL 00/32] Next pr patches
by Daniel P. Berrangé 03 Apr '26

03 Apr '26

The following changes since commit 53b41bb78950912ba2d9809eef6b45e4df30c647: Merge tag 'pull-target-arm-20251031' of https://gitlab.com/pm215/qemu into staging (2025-11-01 10:52:48 +0100) are available in the Git repository at: https://gitlab.com/berrange/qemu tags/next-pr-pull-request for you to fetch changes up to 2aaca8c6d22b18786ceff51189704113d0639590: docs: creation of x509 certs compliant with post-quantum crypto (2025-11-03 10:45:55 +0000) ---------------------------------------------------------------- Merge crypto and other misc fixes / features * Increase minimum gnutls to 3.7.5 * Increase minimum libgcrypt to 1.9.4 * Increase minimum nettle to 3.7.3 * Drop obsolete in-tree XTS impl * Fix memory leak when loading certificates * Remove/reduce duplication when loading certifcates * Fix possible crash when certificates are unloaded while an active TLS connection is using when in a TLS handshake operation * Deprecate use of dh-params.pem file * Document how to create certificates with Post-Quantum Cryptography compliant algorithms. * Support loading multiple certificate identities to allow support for Post-Quantum crypto in parallel with traditional RSA/ECC * Add "-run-with exit-with-parent=on" parameter * Flush pending errors when seeing ENOBUFS with a zero-copy send attempt * Fix data buffer parameters in hash & IO channel APIs to use 'void *' ---------------------------------------------------------------- Daniel P. Berrangé (26): crypto: bump min gnutls to 3.7.5 crypto: unconditionally enable gnutls XTS support crypto: bump min libgcrypt to 1.9.4 crypto: bump min nettle to 3.7.3 crypto: drop in-tree XTS cipher mode impl crypto: remove redundant parameter checking CA certs crypto: add missing free of certs array crypto: replace stat() with access() for credential checks crypto: remove redundant access() checks before loading certs crypto: move check for TLS creds 'dir' property crypto: use g_autofree when loading x509 credentials crypto: remove needless indirection via parent_obj field crypto: move release of DH parameters into TLS creds parent crypto: shorten the endpoint == server check in TLS creds crypto: remove duplication loading x509 CA cert crypto: reduce duplication in handling TLS priority strings crypto: introduce method for reloading TLS creds crypto: introduce a wrapper around gnutls credentials crypto: fix lifecycle handling of gnutls credentials objects crypto: make TLS credentials structs private crypto: deprecate use of external dh-params.pem file crypto: avoid loading the CA certs twice crypto: avoid loading the identity certs twice crypto: expand logic to cope with multiple certificate identities crypto: support upto 5 parallel certificate identities docs: creation of x509 certs compliant with post-quantum crypto Manish Mishra (1): io: flush zerocopy socket error queue on sendmsg failure due to ENOBUF Philippe Mathieu-Daudé (2): crypto/hash: Have hashing functions take void * buffer argument io/channel: Have read/write functions take void * buffer argument Richard W.M. Jones (2): Implement -run-with exit-with-parent=on tests/qtest: Use exit-with-parent=on in qtest invocations Tejus GK (1): io: add a "blocking" field to QIOChannelSocket crypto/cipher-gnutls.c.inc | 8 - crypto/cipher-nettle.c.inc | 44 -- crypto/cipher.c | 2 +- crypto/hash.c | 16 +- crypto/hmac.c | 8 +- crypto/meson.build | 10 +- crypto/tlscreds.c | 79 ++-- crypto/tlscredsanon.c | 64 +-- crypto/tlscredsbox.c | 101 +++++ crypto/tlscredsbox.h | 50 +++ crypto/tlscredspriv.h | 36 +- crypto/tlscredspsk.c | 64 ++- crypto/tlscredsx509.c | 593 +++++++++++++++++--------- crypto/tlssession.c | 139 ++---- crypto/trace-events | 1 + crypto/xts.c | 250 ----------- docs/about/deprecated.rst | 9 + docs/system/tls.rst | 134 +++++- include/crypto/hash.h | 8 +- include/crypto/hmac.h | 4 +- include/crypto/tlscreds.h | 26 ++ include/crypto/tlscredsx509.h | 6 + include/crypto/tlssession.h | 4 +- include/crypto/xts.h | 82 ---- include/io/channel-socket.h | 6 + include/io/channel.h | 14 +- include/qemu/exit-with-parent.h | 57 +++ io/channel-socket.c | 86 +++- io/channel-tls.c | 4 +- io/channel.c | 14 +- meson.build | 69 +-- qemu-options.hx | 13 +- system/exit-with-parent.c | 140 ++++++ system/meson.build | 1 + system/vl.c | 13 + tests/qtest/libqtest.c | 22 +- tests/unit/meson.build | 3 - tests/unit/test-crypto-block.c | 3 +- tests/unit/test-crypto-tlscredsx509.c | 8 +- tests/unit/test-crypto-tlssession.c | 4 +- tests/unit/test-crypto-xts.c | 529 ----------------------- ui/vnc.c | 9 +- 42 files changed, 1208 insertions(+), 1525 deletions(-) create mode 100644 crypto/tlscredsbox.c create mode 100644 crypto/tlscredsbox.h delete mode 100644 crypto/xts.c delete mode 100644 include/crypto/xts.h create mode 100644 include/qemu/exit-with-parent.h create mode 100644 system/exit-with-parent.c delete mode 100644 tests/unit/test-crypto-xts.c -- 2.51.1

2 33

[PATCH v5 0/3] nwfilter: add nwfilter nftables driver
by Dion Bosschieter 30 Mar '26

30 Mar '26

This series aims to implement nftables as a backend driver for the nwfilter feature. The idea is that it will replace the ebiptables driver and provide an easy way for users to switch from one driver to another. The 1st patch introduces the new nwfilter driver. After which nwfilter allows users to choose it in the 2nd patch. The last patch introduces unit testing of the new nftables driver. - Implemented very basic nwfilter.conf reading and choosing a nwfilter driver based on the name of the drivers (nftables/ebiptables). Defaults to the nftables driver, based on the firewall_backend_priority meson option, following the bridge driver logic. - Resolves issue https://gitlab.com/libvirt/libvirt/-/issues/603 benchmarks showed that the amount of iifname jumps for each interface with is the cause for this. Switched the nftables driver towards a vmap (verdict map) so we can have 1 rule that jumps to the correct root input/output chain per interface. Which improves throughput as when the number of interface check and jump rules increases the throughput decreases. The issue describes the interface matching works using the interface name and the majority of the effort is the strncpy, this commit also switches nftables to an interface_index compare instead. However, just using the interface_index is not enough, the amount of oif and iif jump rules causes quite a performance issue, the vmap instead solves this. - Split rules into separate tables: "libvirt-nwfilter-ethernet" and "libvirt-nwfilter-other" to preserve existing firewall behavior. - Reworked chain logic for clarity with root -input/-output chains per interface. input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). - Stuck with prerouting and postrouting as hooks for input / output on the -ethernet and -other table. This makes it easier to merge the tables in the future. Saving management of two tables and decreasing the amount of tables a packet sees. Currently ebtables filtering happens via PREROUTING and POSTROUTING hooks, while ip/ip6tables filtering happens in the output/forward hooks. - Stuck with 2 tables for compatibility reasons with eb iptables, unifying into 1 table will break users firewall definitions, which depend on being able to do accepts on ethernet rules (which currently get defined via ebtables) and additional filtering via the ip rules (which currently get defined via ip(6)tables). The nwfilter_nftables_driver keeps splitting the ethernet and non ethernet (other) rules in seperate tables "libvirt-nwfilter-ethernet" and "libvirt-nwfilter-other". - Rewrote chain logic, so it is easier to understand, input in the VM interface is filtered in the -input chain(s), output out of the VM inteface is filtered in the -output chain(s). -ethernet and -other table follow the same style and hook in the same way. - Simplified conntrack handling: rules with accept+conntrack are duplicated to the opposite chain for symmetric behavior, to support the existing ebiptables logic. - Firewall updates continue use tmp names for atomic replacement. Unsupported nwfilter features (for now): - STP filtering - Gratuitous ARP filtering - IPSets (potential future support via nft sets) - Reject due to filtering in pre/postrouting, using drop instead of reject, copying logic from existing ebiptables ebtables actions Future improvements: - Use `nft -f` for atomic rule application. - Optional single-table mode via nwfilter.conf. - Optimize boot phase with chain hash comparison. --- Changes in v5: - Fix rarp support via nft raw payload expression Changes in v4: - Fix rarp nft commands "arp saddr ether" "arp daddr ether" - Filter chain creation, don't create unnecessary chains - Apply danpb seperate argument suggestion - Fix table not existing errors in drop all rules - Fix table not existing errors in apply basic rules Changes in v3: - Renamed -other to -inet - Renamed - to _ in table names - Updated rule / chain sorting on ethernet table to to copy ebtables logic - Fix possible broken revert path - Fix remove rules not working in some cases, EBUSY - Shared functions camel case commit - Rename config option - Add extra config params, enable_trace, enable_counters This required passing the config struct to the ebip/nft nwfilter drivers - Add extra augeaus files Changes in v2: - Rename {ebip,nf}tables specific test files in 1 directory instead of seperating them in different directories. - Added default nwfilter.conf file in git, documented including augeas files - Replaced hardcoding of default driver based on existing firewall_backend_priority meson option. - Added nwfilter_driver_conf.{h,c} for configuration handling, to match the common pattern used in other drivers. Dion Bosschieter (3): nwfilter: add nwfilter nftables driver nwfilter: allow use of nftables nwfilter driver via nwfilter.conf nwfilter: add unit tests and test data for nwfilter nftables driver libvirt.spec.in | 7 + po/POTFILES | 2 + src/conf/virnwfilterobj.h | 20 - src/nwfilter/libvirtd_nwfilter.aug | 45 + src/nwfilter/meson.build | 38 + src/nwfilter/nwfilter.conf.in | 50 + src/nwfilter/nwfilter_driver.c | 66 +- src/nwfilter/nwfilter_driver_conf.c | 214 + src/nwfilter/nwfilter_driver_conf.h | 69 + src/nwfilter/nwfilter_ebiptables_driver.c | 4 +- src/nwfilter/nwfilter_ebiptables_driver.h | 2 +- src/nwfilter/nwfilter_gentech_driver.c | 65 +- src/nwfilter/nwfilter_gentech_driver.h | 5 +- src/nwfilter/nwfilter_nftables_driver.c | 2668 ++++++++++++ src/nwfilter/nwfilter_nftables_driver.h | 28 + src/nwfilter/nwfilter_tech_driver.h | 3 +- src/nwfilter/test_libvirtd_nwfilter.aug.in | 7 + tests/meson.build | 2 + tests/nwfilternftablestest.c | 426 ++ .../ah-ipv6-linux.nftables.args | 310 ++ .../ah-linux.nftables.args | 304 ++ .../all-ipv6-linux.nftables.args | 292 ++ .../all-linux.nftables.args | 286 ++ .../arp-linux.nftables.args | 231 + .../nwfilterxml2firewalldata/arp.nftables.xml | 27 + .../comment-linux.nftables.args | 510 +++ .../conntrack-linux.nftables.args | 198 + .../esp-ipv6-linux.nftables.args | 310 ++ .../esp-linux.nftables.args | 304 ++ .../example-1-linux.nftables.args | 268 ++ .../example-2-linux.nftables.args | 352 ++ .../hex-data-linux.nftables.args | 384 ++ .../icmp-direction-linux.nftables.args | 238 ++ .../icmp-direction2-linux.nftables.args | 238 ++ .../icmp-direction3-linux.nftables.args | 184 + .../icmp-linux.nftables.args | 256 ++ .../icmpv6-linux.nftables.args | 328 ++ .../igmp-linux.nftables.args | 304 ++ .../ip-linux.nftables.args | 205 + .../ipt-no-macspoof-linux.nftables.args | 172 + .../ipv6-linux.nftables.args | 511 +++ .../iter1-linux.nftables.args | 304 ++ .../iter2-linux.nftables.args | 3760 +++++++++++++++++ .../iter3-linux.nftables.args | 430 ++ .../mac-linux.nftables.args | 184 + .../rarp-linux.nftables.args | 215 + .../sctp-ipv6-linux.nftables.args | 328 ++ .../sctp-linux.nftables.args | 328 ++ .../target-linux.nftables.args | 466 ++ .../target2-linux.nftables.args | 322 ++ .../tcp-ipv6-linux.nftables.args | 328 ++ .../tcp-linux.nftables.args | 476 +++ .../udp-ipv6-linux.nftables.args | 328 ++ .../udp-linux.nftables.args | 328 ++ .../udplite-ipv6-linux.nftables.args | 310 ++ .../udplite-linux.nftables.args | 304 ++ .../vlan-linux.nftables.args | 271 ++ .../ah-ipv6-linux.args | 304 ++ .../nwfilterxml2nftfirewalldata/ah-linux.args | 298 ++ .../all-ipv6-linux.args | 286 ++ .../all-linux.args | 280 ++ .../arp-linux.args | 215 + tests/nwfilterxml2nftfirewalldata/arp.xml | 27 + .../comment-linux.args | 483 +++ .../conntrack-linux.args | 198 + .../esp-ipv6-linux.args | 304 ++ .../esp-linux.args | 298 ++ .../example-1-linux.args | 266 ++ .../example-2-linux.args | 348 ++ .../hex-data-linux.args | 357 ++ .../icmp-direction-linux.args | 238 ++ .../icmp-direction2-linux.args | 238 ++ .../icmp-direction3-linux.args | 184 + .../icmp-linux.args | 252 ++ .../icmpv6-linux.args | 322 ++ .../igmp-linux.args | 298 ++ .../nwfilterxml2nftfirewalldata/ip-linux.args | 198 + .../ipt-no-macspoof-linux.args | 169 + .../ipv6-linux.args | 474 +++ .../iter1-linux.args | 298 ++ .../iter2-linux.args | 3598 ++++++++++++++++ .../iter3-linux.args | 418 ++ .../mac-linux.args | 180 + .../rarp-linux.args | 215 + .../sctp-ipv6-linux.args | 314 ++ .../sctp-linux.args | 314 ++ .../target-linux.args | 452 ++ .../target2-linux.args | 316 ++ .../tcp-ipv6-linux.args | 314 ++ .../tcp-linux.args | 468 ++ .../udp-ipv6-linux.args | 314 ++ .../udp-linux.args | 314 ++ .../udplite-ipv6-linux.args | 304 ++ .../udplite-linux.args | 298 ++ .../vlan-linux.args | 264 ++ tests/nwfilterxml2nftfirewalltest.c | 438 ++ 96 files changed, 33369 insertions(+), 102 deletions(-) create mode 100644 src/nwfilter/libvirtd_nwfilter.aug create mode 100644 src/nwfilter/nwfilter.conf.in create mode 100644 src/nwfilter/nwfilter_driver_conf.c create mode 100644 src/nwfilter/nwfilter_driver_conf.h create mode 100644 src/nwfilter/nwfilter_nftables_driver.c create mode 100644 src/nwfilter/nwfilter_nftables_driver.h create mode 100644 src/nwfilter/test_libvirtd_nwfilter.aug.in create mode 100644 tests/nwfilternftablestest.c create mode 100755 tests/nwfilterxml2firewalldata/ah-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ah-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/all-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/arp-linux.nftables.args create mode 100644 tests/nwfilterxml2firewalldata/arp.nftables.xml create mode 100755 tests/nwfilterxml2firewalldata/comment-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/conntrack-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/esp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/example-2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/hex-data-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-direction3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/icmpv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/igmp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ip-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipt-no-macspoof-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter1-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/iter3-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/mac-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/rarp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/sctp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/target2-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/tcp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udp-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-ipv6-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/udplite-linux.nftables.args create mode 100755 tests/nwfilterxml2firewalldata/vlan-linux.nftables.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ah-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ah-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/all-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/all-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/arp-linux.args create mode 100644 tests/nwfilterxml2nftfirewalldata/arp.xml create mode 100755 tests/nwfilterxml2nftfirewalldata/comment-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/conntrack-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/esp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/esp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/example-1-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/example-2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/hex-data-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-direction-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-direction2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-direction3-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/icmpv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/igmp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ip-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ipt-no-macspoof-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/iter1-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/iter2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/iter3-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/mac-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/rarp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/sctp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/sctp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/target-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/target2-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/tcp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/tcp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udp-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udp-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udplite-ipv6-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/udplite-linux.args create mode 100755 tests/nwfilterxml2nftfirewalldata/vlan-linux.args create mode 100644 tests/nwfilterxml2nftfirewalltest.c -- 2.43.0

2 10

[PATCH v6 0/6] cover: RFE libvirt secret encryption on disk
by Arun Menon 30 Mar '26

30 Mar '26

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object is using, we can encrypt the secrets on disk and store them in <uuid>.<encryption_scheme> format. It is important to note that if the encryption key is changed between restarts, then the respective secret will not be loaded by the driver. 6. Add documentation. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 --- Changes in v6: - changes to use obj->secretValueFile as base - does local suffix lookups - refactors code so that the base64 encoding is in common code paths - moves local variable declaration inside blocks using them - refactors loader to use virFileReadAll instead of open-coding - fixes virSecretObjDeleteData to not rely on the actual filename Changes in v5: - Fix the bug of updating old secrets, prior to 12.1.0. Old secrets, when updated, now are stored with the latest encryption scheme if encryption is on. - Remove any logic in setting the secretValueFile in virSecretObjListAdd. Move it to virSecretLoadValue and virSecretObjSetValue. - Change urandom to random. Change default permission bits to 0077. - Update the documentation. Changes in v4: - Fix the regression of loading unencrypted secrets after an upgrade. Previously the .base64 unencrypted secrets were not being loaded. - Add documentation on encrypted secrets. Changes in v3: - Secrets xml configuration no longer stores the encryption scheme, therefore not allowing the user to toggle between ciphers. - Removed unnecessary socket files of the new service. It now has a general configuration with which it starts. - Addressed review comments from Peter on coding style and design. - Loading of secrets is dependent on the file extension. Most recent cipher is used while saving the secrets. Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (6): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secret.conf configuration file and parse it secret: Rename virSecretObj structure attribute from base64File to secretValueFile secret: Add functionality to load and save secrets in encrypted format docs: secret: Add documentation of secret encryption feature docs/drvsecret.rst | 4 + docs/meson.build | 1 + docs/secretencryption.rst | 105 +++++++++ include/libvirt/virterror.h | 1 + libvirt.spec.in | 8 + po/POTFILES | 1 + src/conf/virsecretobj.c | 210 +++++++++++++----- src/conf/virsecretobj.h | 14 +- src/libvirt_private.syms | 1 + src/meson.build | 1 + src/remote/libvirtd.service.in | 4 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 32 +++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 179 +++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 29 ++- src/secret/test_libvirt_secrets.aug.in | 6 + .../virt-secret-init-encryption.service.in | 8 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 126 ++++++++++- src/util/vircrypto.h | 8 + src/util/virerror.c | 3 + tests/vircryptotest.c | 65 ++++++ 24 files changed, 840 insertions(+), 68 deletions(-) create mode 100644 docs/secretencryption.rst create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret.conf.in create mode 100644 src/secret/secret_config.c create mode 100644 src/secret/secret_config.h create mode 100644 src/secret/test_libvirt_secrets.aug.in create mode 100644 src/secret/virt-secret-init-encryption.service.in -- 2.51.1

4 15

[RFC] Reintroducing customisable hotplug timeouts
by Akash Kulhalli 30 Mar '26

30 Mar '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 12

[PATCH v2] virhostcpu: Fix potential use of unallocated memory
by Felix Huettner 26 Mar '26

26 Mar '26

In case of a host that has a large number of cpus offline the count of host cpus and the last bit set in the virHostCPUGetOnlineBitmap might diverge significantly. This can e.g. be the case when disabling smt via /sys/devices/system/cpu/smt/control. On the host this looks like: ``` $ cat /sys/devices/system/cpu/present 0-255 $ cat /sys/devices/system/cpu/online 0-127 ``` However in this case virBitmapToData previously only allocated 16 bytes for the output bitmap. This is becase the last set bit is on the 15th byte. Users of virHostCPUGetMap however rely on the "cpumap" containing enough space for all existing cpus (so they would expect 32 bytes in this case). E.g. cmdNodeCpuMap relies on this for its output. It will then actually read 32 bytes from the start of the "cpumap" address where in this case the last 16 of these bytes are uninitialized. This manifests itself in flapping outputs of "virsh nodecpumap --pretty" like: ``` $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,202 $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,197 $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,196-197 ``` This in turn potentially causes users of this data to report wrong cpu counts. Note that this only seems to happen with at least 256 physical cpus where at least 128 are offline. We fix this by preallocating the expected bitmap size. Signed-off-by: Felix Huettner <felix.huettner(a)stackit.cloud> --- src/util/virhostcpu.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 5dbcc8987c..4805484b1d 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1090,28 +1090,26 @@ virHostCPUGetMap(unsigned char **cpumap, unsigned int flags) { g_autoptr(virBitmap) cpus = NULL; - int ret = -1; - int dummy; + int ncpus = virHostCPUGetCount(); virCheckFlags(0, -1); if (!cpumap && !online) - return virHostCPUGetCount(); + return ncpus; if (!(cpus = virHostCPUGetOnlineBitmap())) - goto cleanup; + return -1; + + if (cpumap) { + int len = (ncpus + CHAR_BIT) / CHAR_BIT; + *cpumap = g_new0(unsigned char, len); + virBitmapToDataBuf(cpus, *cpumap, len); + } - if (cpumap) - virBitmapToData(cpus, cpumap, &dummy); if (online) *online = virBitmapCountBits(cpus); - ret = virHostCPUGetCount(); - - cleanup: - if (ret < 0 && cpumap) - VIR_FREE(*cpumap); - return ret; + return ncpus; } base-commit: c5a73f75bc6cae4f466d0a6344d5b3277ac9c2f4 -- 2.43.0

2 1

[PATCH v2 00/21] qom: introduce property flags to track external user input
by Zhao Liu 23 Mar '26

23 Mar '26

Hi, This is the v2 trying to introduce property flags to detect user's property setting (from CLI/QMP/HMP). I dropped RFC tag since previous RFC v1 [1]. Though this work the follow-up of v2.6 & v2.7 machines' removal [2], now it is decoupled from [2] totally since v2 doesn't detect compat property and only focuses on external user setting, so this series is based on master branch at the commit 28a6ca268c2c ("Merge tag 'single- binary-20260203' of https://github.com/philmd/qemu into staging"). And you can also find the code here: https://gitlab.com/zhao.liu/qemu/-/tree/prop-flags-v2.3-02-08-2026 This series introduces 3 property flags: * USER_SET: Any external user property setting (from CLI/HMP/QMP) is marked as USER_SET. * DEPRECATED: Once a property is marked as DEPRECATED, any external user property setting will trigger a warning. * INTERNAL: Once a property is marked as INTERNAL, any external user property setting will cause an error. More details or document for these 3 flags, you can refer patch 7. Compared with RFC v1, v2 mainly: * introduce USER_SET property flag to identify all user's setting. - patch 7 for document. * construct DEPRECATED & INTERNAL flag on USER_SET. - patch 7 for document. * cover more comprehensive user set cases. - patch 8-13. * provide examples about new flags (USER_SET/DEPRECATED/INTELNAL). - patch 15/16/17 are examples for DEPRECATED flag. - patch 18 is the example for INTERNAL flag. - patch 20 is the example for USER_SET flag. I think v2 should now cover "nearly" all cases (patch 8-13) where users set properties: one approach is to trace the call chain of object_property_set(). Even if there are cases that were missed, they can be easily addressed based on this series: object_property_set(obj, ...); /* Insert this call after object_property_set(). */ object_property_set_flags(obj, ..., OBJ_PROP_FLAG_USER_SET, ...); [1]: RFC v1: https://lore.kernel.org/qemu-devel/20251202170502.3228625-1-zhao1.liu@intel… [2]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20260108033051.777361-1-zhao1.liu@intel.… Thanks and Best Regards, Zhao --- Zhao Liu (21): qom/object: use BIT macro for ObjectPropertyFlags qom/object: cache ObjectPropertyFlags in ObjectProperty qom/object: factor out object_class_property_try_add() qom/object: add flags argument in object_{class_}property_try_add() qom/object: rename object_{class_}property_try_add() to object_{class_}property_add_full() qom/object: add helpers to set/get/clear property flags qom/object: introduce user interaction flags for properties qom/object: add from_user argument in object_property_parse() qom/object: mark global property set from CLI as USER_SET qom/qom-hmp-cmd: mark properties set from HMP (non-JSON) "qom-set" as USER_SET qom/qom-qmp-cmd: mark properties set from QMP/HMP (JSON) "qom-set" as USER_SET qom/object_interfaces: mark properties set from qdict & keyval as USER_SET system/vl: mark property set in object_parse_property_opt() as USER_SET hw/core/qdev-properties: allow qdev properties accept flags target/i386: deprecate fill-mtrr-mask property target/i386: deprecate cpuid-0xb property hw/intc/ioapic: deprecate version property target/i386: mark x-consistent-cache property as internal-only target/i386: remove redundant validation for lbr-fmt property target/i386: detect user provided lbr-fmt via property flag hw/core/qdev-properties: support valid default value for DEFINE_PROP_UINT64_CHECKMASK docs/about/deprecated.rst | 31 +++++ hw/core/qdev-properties.c | 29 ++-- hw/i386/sgx.c | 2 +- hw/intc/ioapic.c | 3 +- include/hw/core/qdev-properties.h | 38 +++--- include/qom/object.h | 215 +++++++++++++++++++++++++++--- qom/object.c | 177 ++++++++++++++++++++---- qom/object_interfaces.c | 5 + qom/qom-hmp-cmds.c | 2 +- qom/qom-qmp-cmds.c | 7 +- system/vl.c | 6 +- target/i386/cpu.c | 28 ++-- 12 files changed, 448 insertions(+), 95 deletions(-) -- 2.34.1

9 44

[PATCH v2 0/2] Adding support for client-based FD migrations.
by Tejus GK 20 Mar '26

20 Mar '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 :) V2: 1. Removed the approach of introducing a new FD passing API and instead reuse the virDomainFDAssociate API along with a dummy VM on the destination host. 2. Introduced a new virDomainMigrate parameter, VIR_MIGRATE_PARAM_FD_SET. Tejus GK (2): qemu: support incoming "fd" uri qemu: add support for fd based live migrations include/libvirt/libvirt-domain.h | 14 +++ src/qemu/qemu_driver.c | 24 +++-- src/qemu/qemu_migration.c | 174 +++++++++++++++++++++++++------ src/qemu/qemu_migration.h | 3 + 4 files changed, 178 insertions(+), 37 deletions(-) -- 2.43.7

2 4

[PATCH 0/2] storage: fix pool refresh failure during async jobs
by Lucas Amaral 20 Mar '26

20 Mar '26

When creating multiple VMs in parallel using virt-install, pool refresh fails with: error: internal error: pool 'default' has asynchronous jobs running. This happens because a concurrent volume creation holds an async job on the pool. The storagePoolRefresh() function immediately returns VIR_ERR_INTERNAL_ERROR instead of waiting for the async job to finish. Patch 1 fixes the error code from VIR_ERR_INTERNAL_ERROR to VIR_ERR_OPERATION_INVALID in all 4 affected operations (pool-refresh, pool-destroy, pool-undefine, pool-delete), consistent with the adjacent "pool is not active" and "pool is starting up" checks. Patch 2 adds a condition variable to virStoragePoolObj so that storagePoolRefresh() waits up to 30 seconds for async jobs to drain instead of failing immediately. The other three operations keep the immediate error since waiting to destroy/delete/undefine a pool during volume creation is not a sensible user workflow. Reproducing the bug requires artificially widening the race window since fallocate() completes in microseconds on local filesystems. I used LD_PRELOAD to inject a 15-second delay into fallocate64() for files in the pool directory. Details and validation results are in the individual patch notes below the '---' line. https://issues.redhat.com/browse/RHEL-150758 Lucas Amaral (2): storage: fix error code for async jobs check in pool operations storage: wait for async jobs to drain during pool refresh src/conf/virstorageobj.c | 39 ++++++++++++++++++++++++++++++++++++ src/conf/virstorageobj.h | 3 +++ src/libvirt_private.syms | 1 + src/storage/storage_driver.c | 25 ++++++++++++++++------- 4 files changed, 61 insertions(+), 7 deletions(-) -- 2.52.0

2 5

[PATCH] qemu: add automatic port allocation for pull-mode backup NBD servers
by Lucas Amaral 20 Mar '26

20 Mar '26

Previously, users had to manually specify a TCP port when starting a pull-mode backup with an NBD server. A TODO comment in qemuBackupPrepare() noted this limitation and pointed toward using virPortAllocator, as done for migration, VNC, and SPICE ports. Add backup_port_min and backup_port_max configuration options to qemu.conf, defaulting to 10809-10872 (10809 is the IANA-assigned NBD port; range of 64 matches the migration port pattern). When a pull-mode backup is started without specifying a TCP port, a port is now acquired automatically from the configured range via virPortAllocatorAcquire(). The port is released when the backup ends or if startup fails. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- Build-tested and passed full test suite on CentOS Stream 9 (298 OK, 0 failures). Runtime-validated against an actual patched virtqemud instance running inside a privileged container (CentOS Stream 9, QEMU 10.1.0) with a live aarch64/virt guest. Config parsing validation: - Default config (no backup_port_* set): daemon starts OK - Custom range (backup_port_min=20000, backup_port_max=20010): daemon starts OK - Invalid (min > max): daemon correctly refuses to start - Invalid (min = 0): daemon correctly refuses to start - Invalid (max > 65535): daemon correctly refuses to start Port auto-allocation (live VM backup): - Pull-mode backup WITHOUT port specified: backup-begin succeeds, backup-dumpxml shows auto-allocated port='10809' from default range. Previously this would fail with: "<domainbackup> must specify TCP port for now" - Pull-mode backup WITH explicit port=10809: backup-begin succeeds, backup-dumpxml shows port='10809'. Behavior unchanged from before the patch. Port conflict and exhaustion (range set to 10809-10810, 3 VMs): - Auto-allocate on vm1 (got 10809), then manual port=10809 on vm2: QEMU correctly rejects with "Address already in use" - Auto-allocate vm1=10809, vm2=10810 (range full), vm3 attempt: "Unable to find an unused port in range 'backup' (10809-10810)" - After aborting vm1 backup (releasing 10809), vm3 retries and gets 10809: port release and reuse works correctly docs/formatbackup.rst | 3 ++- src/qemu/libvirtd_qemu.aug | 2 ++ src/qemu/qemu.conf.in | 9 ++++++++ src/qemu/qemu_backup.c | 33 +++++++++++++++++++++--------- src/qemu/qemu_conf.c | 25 ++++++++++++++++++++++ src/qemu/qemu_conf.h | 6 ++++++ src/qemu/qemu_domain.h | 1 + src/qemu/qemu_driver.c | 6 ++++++ src/qemu/test_libvirtd_qemu.aug.in | 2 ++ 9 files changed, 76 insertions(+), 11 deletions(-) diff --git a/docs/formatbackup.rst b/docs/formatbackup.rst index df6392e3bd..24857eaf72 100644 --- a/docs/formatbackup.rst +++ b/docs/formatbackup.rst @@ -42,7 +42,8 @@ were supplied). The following child elements and attributes are supported: ```protocol`` element of a disk <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ attached via NBD in the domain (such as transport, socket, name, port, or tls), necessary to set up an NBD server that exposes the content of each disk at - the time the backup is started. + the time the backup is started. For TCP transport, if ``port`` is omitted, a + port is allocated automatically from the range configured in ``/etc/libvirt/qemu.conf``. In addition to the above the NBD server used for backups allows using ``transport='fd' fdgroup='NAME'`` where ``NAME`` is the name used with diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug index 0286582169..eb790d48be 100644 --- a/src/qemu/libvirtd_qemu.aug +++ b/src/qemu/libvirtd_qemu.aug @@ -146,6 +146,8 @@ module Libvirtd_qemu = | int_entry "migration_port_min" | int_entry "migration_port_max" | str_entry "migration_host" + | int_entry "backup_port_min" + | int_entry "backup_port_max" let log_entry = bool_entry "log_timestamp" diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in index 2d1c67034d..5eacd70022 100644 --- a/src/qemu/qemu.conf.in +++ b/src/qemu/qemu.conf.in @@ -969,6 +969,15 @@ #migration_port_max = 49215 +# Port range used for automatic allocation of NBD backup server ports. +# When a pull-mode backup is started without specifying a TCP port, a +# port from this range will be assigned automatically. The NBD standard +# port is 10809. +# +#backup_port_min = 10809 +#backup_port_max = 10872 + + # Timestamp QEMU's log messages (if QEMU supports it) # # Defaults to 1. diff --git a/src/qemu/qemu_backup.c b/src/qemu/qemu_backup.c index 44514d08fc..12ef64b14e 100644 --- a/src/qemu/qemu_backup.c +++ b/src/qemu/qemu_backup.c @@ -32,6 +32,7 @@ #include "storage_source.h" #include "storage_source_conf.h" #include "virerror.h" +#include "virportallocator.h" #include "virlog.h" #include "virbuffer.h" #include "backup_conf.h" @@ -71,16 +72,7 @@ qemuBackupPrepare(virDomainBackupDef *def) switch (def->server->transport) { case VIR_STORAGE_NET_HOST_TRANS_TCP: - /* TODO: Update qemu.conf to provide a port range, - * probably starting at 10809, for obtaining automatic - * port via virPortAllocatorAcquire, as well as store - * somewhere if we need to call virPortAllocatorRelease - * during BackupEnd. Until then, user must provide port */ - if (!def->server->port) { - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("<domainbackup> must specify TCP port for now")); - return -1; - } + /* port is auto-allocated if not set */ break; case VIR_STORAGE_NET_HOST_TRANS_UNIX: @@ -841,6 +833,16 @@ qemuBackupBegin(virDomainObj *vm, if (qemuBackupPrepare(def) < 0) goto endjob; + if (pull && def->server && + def->server->transport == VIR_STORAGE_NET_HOST_TRANS_TCP && + !def->server->port) { + unsigned short port = 0; + if (virPortAllocatorAcquire(priv->driver->backupPorts, &port) < 0) + goto endjob; + def->server->port = port; + priv->backupNBDPort = port; + } + if (qemuBackupBeginPrepareTLS(vm, cfg, def, &tlsProps, &tlsSecretProps) < 0) goto endjob; @@ -969,6 +971,11 @@ qemuBackupBegin(virDomainObj *vm, qemuDomainObjExitMonitor(vm); } + if (ret < 0 && priv->backupNBDPort) { + virPortAllocatorRelease(priv->backupNBDPort); + priv->backupNBDPort = 0; + } + if (ret < 0 && !job_started && priv->backup) def = g_steal_pointer(&priv->backup); @@ -1026,6 +1033,12 @@ qemuBackupNotifyBlockjobEndStopNBD(virDomainObj *vm, qemuDomainObjExitMonitor(vm); backup->nbdStopped = true; + + if (priv->backupNBDPort) { + virPortAllocatorRelease(priv->backupNBDPort); + priv->backupNBDPort = 0; + backup->server->port = 0; + } } diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index de6e51177a..99e6a29148 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -74,6 +74,9 @@ VIR_LOG_INIT("qemu.qemu_conf"); #define QEMU_MIGRATION_PORT_MIN 49152 #define QEMU_MIGRATION_PORT_MAX 49215 +#define QEMU_BACKUP_PORT_MIN 10809 +#define QEMU_BACKUP_PORT_MAX 10872 + VIR_ENUM_IMPL(virQEMUSchedCore, QEMU_SCHED_CORE_LAST, "none", @@ -265,6 +268,9 @@ virQEMUDriverConfig *virQEMUDriverConfigNew(bool privileged, cfg->migrationPortMin = QEMU_MIGRATION_PORT_MIN; cfg->migrationPortMax = QEMU_MIGRATION_PORT_MAX; + cfg->backupPortMin = QEMU_BACKUP_PORT_MIN; + cfg->backupPortMax = QEMU_BACKUP_PORT_MAX; + /* For privileged driver, try and find hugetlbfs mounts automatically. * Non-privileged driver requires admin to create a dir for the * user, chown it, and then let user configure it manually. */ @@ -985,6 +991,25 @@ virQEMUDriverConfigLoadNetworkEntry(virQEMUDriverConfig *cfg, return -1; } + if (virConfGetValueUInt(conf, "backup_port_min", &cfg->backupPortMin) < 0) + return -1; + if (cfg->backupPortMin <= 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("%1$s: backup_port_min: port must be greater than 0"), + filename); + return -1; + } + + if (virConfGetValueUInt(conf, "backup_port_max", &cfg->backupPortMax) < 0) + return -1; + if (cfg->backupPortMax > 65535 || + cfg->backupPortMax < cfg->backupPortMin) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("%1$s: backup_port_max: port must be between the minimal port %2$d and 65535"), + filename, cfg->backupPortMin); + return -1; + } + if (virConfGetValueString(conf, "migration_host", &cfg->migrateHost) < 0) return -1; virStringStripIPv6Brackets(cfg->migrateHost); diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index c284e108a1..2e68f1de14 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -240,6 +240,9 @@ struct _virQEMUDriverConfig { unsigned int migrationPortMin; unsigned int migrationPortMax; + unsigned int backupPortMin; + unsigned int backupPortMax; + bool logTimestamp; bool stdioLogD; @@ -338,6 +341,9 @@ struct _virQEMUDriver { /* Immutable pointer, immutable object */ virPortAllocatorRange *migrationPorts; + /* Immutable pointer, immutable object */ + virPortAllocatorRange *backupPorts; + /* Immutable pointer, lockless APIs */ virSysinfoDef *hostsysinfo; diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 5755d2adb0..1153d8c6e0 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -147,6 +147,7 @@ struct _qemuDomainObjPrivate { char *origname; int nbdPort; /* Port used for migration with NBD */ unsigned short migrationPort; + unsigned short backupNBDPort; int preMigrationState; unsigned long long preMigrationMemlock; /* Original RLIMIT_MEMLOCK in case it was changed for the current diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index c5eedeedfa..a8034b4f26 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -714,6 +714,12 @@ qemuStateInitialize(bool privileged, cfg->migrationPortMax)) == NULL) goto error; + if ((qemu_driver->backupPorts = + virPortAllocatorRangeNew(_("backup"), + cfg->backupPortMin, + cfg->backupPortMax)) == NULL) + goto error; + if (qemuSecurityInit(qemu_driver) < 0) goto error; diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in index 82cfec3b4b..2582c6a09c 100644 --- a/src/qemu/test_libvirtd_qemu.aug.in +++ b/src/qemu/test_libvirtd_qemu.aug.in @@ -110,6 +110,8 @@ module Test_libvirtd_qemu = { "migration_host" = "host.example.com" } { "migration_port_min" = "49152" } { "migration_port_max" = "49215" } +{ "backup_port_min" = "10809" } +{ "backup_port_max" = "10872" } { "log_timestamp" = "0" } { "nvram" { "1" = "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" } -- 2.52.0

2 1

[PATCH 0/4] libvirt: AMD IOMMU fixes
by Xiaotian Feng 13 Mar '26

13 Mar '26

This series refines libvirt's logic for large vCPU configurations (>255) on x86/q35 machine types. Historically, the threshold was tied to Intel's EIM capability, but the real requirement is x2APIC support for APIC IDs beyond 255. AMD platforms can satisfy this via xtsup on amd-iommu. Summary of changes: 1. Fix virDomainIOMMUDefEquals to include pt and xtsup attributes for proper checks. 2. Correct error messages for passthrough (pt) and xtsup attributes to reflect their actual names instead of "dma translation". 3. Rename QEMU_MAX_VCPUS_WITHOUT_EIM to QEMU_MAX_VCPUS_WITHOUT_X2APIC and update validation logic to accept either: - intel-iommu with eim='on', or - amd-iommu with xtsup='on' for guests with more than 255 vCPUs. Error messages now mention x2APIC mode instead of extended interrupt mode. 4. Add QEMU_CAPS_AMD_IOMMU_XTSUP capability and enable xtsup by default for AMD IOMMU when a Q35 domain has >255 vCPUs, similar to Intel EIM auto-enable logic. Also ensure intremap is turned on when required. This makes the behavior vendor-neutral and improves usability for AMD EPYC guests with large vCPU counts. No ABI changes beyond stricter equality checks; this is a clarification and extension of existing logic. Xiaotian Feng (4): conf: fix virDomainIOMMUDefEquals for amd_iommu conf: fix error log for passthrough and xtsup attributes conf: support >255 vcpu w/ amd-iommu xtsup qemu: Enable AMD IOMMU XTSUP by default src/conf/domain_conf.c | 6 ++++-- src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_postparse.c | 42 +++++++++++++++++++++++------------- src/qemu/qemu_validate.c | 11 +++++----- src/qemu/qemu_validate.h | 2 +- 6 files changed, 41 insertions(+), 23 deletions(-) -- 2.34.1

2 6

[PATCH] storage: mpath: fix error reporting in virStorageBackendGetMaps
by Lucas Amaral 13 Mar '26

13 Mar '26

virStorageBackendGetMaps() returns 1 on failure instead of the conventional -1, and does not call virReportError() in any of its error paths. On top of that, both callers silently discard the return value: virStorageBackendGetMaps() ignores the result of virStorageBackendCreateVols(), and virStorageBackendMpathRefreshPool() ignores the result of virStorageBackendGetMaps(). Fix all three issues: normalize error returns to -1, add virReportError() calls for each failure path in virStorageBackendGetMaps(), and check return values in both callers so that errors are properly propagated. Signed-off-by: Lucas Amaral <lucaaamaral(a)gmail.com> --- This is similar in spirit to commits e9b931d3e4 ("virpci: Report an error if virPCIGetVirtualFunctionIndex() fails") and 6c2c9e21ac ("virstorageobj: Make virStoragePoolObjAddVol() report an error on failure"), applying the same pattern to the mpath storage backend. Found while auditing storage backends for functions that return error codes without calling virReportError(). src/storage/storage_backend_mpath.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_backend_mpath.c b/src/storage/storage_backend_mpath.c index 9fc3983c52..a30153a93b 100644 --- a/src/storage/storage_backend_mpath.c +++ b/src/storage/storage_backend_mpath.c @@ -197,19 +197,25 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) struct dm_names *names = NULL; if (!(dmt = dm_task_create(DM_DEVICE_LIST))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to create devmapper task")); + retval = -1; goto out; } dm_task_no_open_count(dmt); if (!dm_task_run(dmt)) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to run devmapper task")); + retval = -1; goto out; } if (!(names = dm_task_get_names(dmt))) { - retval = 1; + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Failed to get devmapper device names")); + retval = -1; goto out; } @@ -218,7 +224,10 @@ virStorageBackendGetMaps(virStoragePoolObj *pool) goto out; } - virStorageBackendCreateVols(pool, names); + if (virStorageBackendCreateVols(pool, names) < 0) { + retval = -1; + goto out; + } out: if (dmt != NULL) @@ -248,7 +257,8 @@ virStorageBackendMpathRefreshPool(virStoragePoolObj *pool) virWaitForDevices(); - virStorageBackendGetMaps(pool); + if (virStorageBackendGetMaps(pool) < 0) + return -1; return 0; } -- 2.52.0

2 1

[PATCH v1 0/1] rpc: fix virNetClient->error leak on teardown
by Leander Kohler 12 Mar '26

12 Mar '26

Hi all, this is my first contribution to libvirt upstream. I am with Cyberus Technology, where I work on cloud-hypervisor and its integration with OpenStack and libvirt. The following fixes a leak in virNetClient teardown. virNetClientMarkClose() may save the current error in client->error (via virSaveLastError()). We usually free that in virNetClientCloseLocked(), but we can also end up disposing the client without going through that cleanup. One path where this happens is: virConnectDispose() -> remoteConnectClose() -> doRemoteClose() -> virNetClientClose(priv->client) -> g_clear_pointer(&priv->client, virObjectUnref) In that case, client->error can stay allocated until finalization, and ASan reports a leak. Fix is to also clear client->error in virNetClientDispose() as a final fallback. I included an ASan trace below. Thanks, Leander --- Line numbers in this trace come from our downstream libvirt fork and may differ from upstream, but the call path/function names are the same. [ 276.247727] virtchd[4030]: ==4030==ERROR: LeakSanitizer: detected memory leaks Direct leak of 80 byte(s) in 1 object(s) allocated from: #0 0x7fcd6009e110 in calloc (libasan.so.8+0xfc110) #1 0x7fcd5dcb95bd in g_malloc0 (libglib-2.0.so.0+0x6d5bd) #2 0x7fcd5eb15f31 in virSaveLastError ../src/util/virerror.c:413 #3 0x7fcd5ee6c76c in virNetClientMarkClose ../src/rpc/virnetclient.c:776 #4 0x7fcd5ee6f782 in virNetClientCloseInternal ../src/rpc/virnetclient.c:837 #5 0x7fcd5f0150e4 in doRemoteClose ../src/remote/remote_driver.c:1414 #6 0x7fcd5f0150e4 in remoteConnectClose ../src/remote/remote_driver.c:1442 #7 0x7fcd5f1a90ef in virConnectDispose ../src/datatypes.c:174 #8 0x7fcd5ea58ebb in vir_object_finalize ../src/util/virobject.c:323 #9 0x7fcd5dc05c52 in g_object_unref (libgobject-2.0.so.0+0x1ec52) #10 0x7fcd5ea59fc7 in virObjectUnref ../src/util/virobject.c:377 #11 0x7fcd5ea59fc7 in virObjectUnref ../src/util/virobject.c:370 #12 0x7fcd5ef3a92f in glib_autoptr_clear_virConnect ../src/datatypes.h:548 #13 0x7fcd5ef3a92f in glib_autoptr_cleanup_virConnect ../src/datatypes.h:548 #14 0x7fcd5ef3a92f in virDomainInterfaceDeleteDevice ../src/hypervisor/domain_interface.c:419 #15 0x7fcd594a0cd3 in virCHProcessStopOrKill ../src/ch/ch_process.c:1308 #16 0x7fcd594a8bfa in virCHProcessStop ../src/ch/ch_process.c:1363 #17 0x7fcd5945d8c7 in chDomainDestroyFlags ../src/ch/ch_driver.c:959 #18 0x7fcd5f0f69c0 in virDomainDestroy ../src/libvirt-domain.c:514 #19 0x55c25777376a in remoteDispatchDomainDestroy src/remote/remote_daemon_dispatch_stubs.h:5485 #20 0x55c25777376a in remoteDispatchDomainDestroyHelper src/remote/remote_daemon_dispatch_stubs.h:5464 #21 0x7fcd5ee7c42c in virNetServerProgramDispatchCall ../src/rpc/virnetserverprogram.c:423 #22 0x7fcd5ee7c42c in virNetServerProgramDispatch ../src/rpc/virnetserverprogram.c:299 #23 0x7fcd5ee97c6c in virNetServerProcessMsg ../src/rpc/virnetserver.c:135 #24 0x7fcd5ee98b43 in virNetServerHandleJob ../src/rpc/virnetserver.c:155 #25 0x7fcd5eadbce2 in virThreadPoolWorker ../src/util/virthreadpool.c:164 #26 0x7fcd5eada3c9 in virThreadHelper ../src/util/virthread.c:256 #27 0x7fcd60004cd5 in asan_thread_start(void*) (libasan.so.8+0x62cd5) #28 0x7fcd5d200979 in start_thread (libc.so.6+0x9a979) #29 0x7fcd5d288d2b in __GI___clone3 (libc.so.6+0x122d2b) Objects leaked above: 0x507000064400 (80 bytes) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 1 allocation(s). Leander Kohler (1): rpc: free saved close error in virNetClientDispose src/rpc/virnetclient.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.51.2

2 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

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

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

[PATCH 0/4] qemuhotplugtest: Introduce interface-hostdev test case
by Michal Privoznik 09 Mar '26

09 Mar '26

Inspired by the following patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/YQHQ… Michal Prívozník (4): virpcimock: Create sriov_totalvfs file and virtfnN symlinks virpcimock: Create net/ subdir for devices virnetdevmock: Mock virNetDevSaveNetConfig() and virNetDevSetNetConfig() qemuhotplugtest: Introduce interface-hostdev test case src/util/virnetdev.h | 5 +- tests/qemuhotplugtest.c | 7 +- .../qemuhotplug-interface-hostdev.xml | 6 ++ ...emuhotplug-base-live+interface-hostdev.xml | 63 +++++++++++++++ tests/virnetdevmock.c | 22 ++++++ tests/virpcimock.c | 78 +++++++++++++++++-- 6 files changed, 171 insertions(+), 10 deletions(-) create mode 100644 tests/qemuhotplugtestdevices/qemuhotplug-interface-hostdev.xml create mode 100644 tests/qemuhotplugtestdomains/qemuhotplug-base-live+interface-hostdev.xml -- 2.52.0

2 5

[PATCH 0/6] qemu: fix a passt bug, add a passt feature
by Laine Stump 09 Mar '26

09 Mar '26

The first patch cleans up a dangling socket that was hanging around after we finished using a passt process in vhostuser mode. The rest are to support specifying the default route for a passt interface with <route gateway='x.x.x.x'/> Laine Stump (6): qemu: delete passt "repair" socket when appropriate qemu: reorganize qemuValidateDomainDeviceDefNetwork() qemu: only limit IPv4 prefix for slirp util: make the route arg to virNetDevIPRouteGetPrefix const conf/util: fix non-specification of IP route destination address qemu: support setting default route for passt interfaces inside the guest src/conf/networkcommon_conf.c | 74 ++++++++------- src/conf/schemas/networkcommon.rng | 4 +- src/qemu/qemu_passt.c | 30 ++++++- src/qemu/qemu_validate.c | 140 +++++++++++++++++++---------- src/util/virnetdevip.c | 14 ++- src/util/virnetdevip.h | 2 +- 6 files changed, 170 insertions(+), 94 deletions(-) -- 2.52.0

3 17

[PATCH 1/2] hyperv: fix flags passed to virDomainDefParseString()
by Jonathon Jongsma 06 Mar '26

06 Mar '26

This function expects flags that are bitwise-or values of the VIR_DOMAIN_DEF_PARSE_* constants, but we were passing two flags that were not part of this flag set: - 1 < VIR_DOMAIN_VIRT_HYPERV - VIR_DOMAIN_XML_INACTIVE Replace VIR_DOMAIN_XML_INACTIVE with VIR_DOMAIN_DEF_PARSE_INACTIVE (which fortunately happens to be the exact same value). Remove flag "1 < VIR_DOMAIN_VIRT_HYPERV", which turns out to the the same value as the flag VIR_DOMAIN_DEF_PARSE_ABI_UPDATE_MIGRATION, which seems unnecessary and undesirable here. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/hyperv/hyperv_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hyperv/hyperv_driver.c b/src/hyperv/hyperv_driver.c index b01b4919fe..8832769c7b 100644 --- a/src/hyperv/hyperv_driver.c +++ b/src/hyperv/hyperv_driver.c @@ -2937,7 +2937,7 @@ hypervDomainDefineXML(virConnectPtr conn, const char *xml) /* parse xml */ def = virDomainDefParseString(xml, priv->xmlopt, NULL, - 1 << VIR_DOMAIN_VIRT_HYPERV | VIR_DOMAIN_XML_INACTIVE); + VIR_DOMAIN_DEF_PARSE_INACTIVE); if (!def) goto error; -- 2.53.0

2 2

[PATCH 0/3] Add 'scalable_mode' and 'first_stage' attributes to intel IOMMU
by Zhenzhong Duan 06 Mar '26

06 Mar '26

Hi, This adds 'scalable_mode' and 'first_stage' attributes to intel IOMMU so that emulated device can run with first stage translation. This is based on Nathan Chen's iommufd series v2[1], so for passthrough device, nested tranlation is enabled automatically with below config: <iommu model='intel'> <driver caching_mode='on' iotlb='on' scalable_mode='on' first_stage='on'/> </iommu> Tests: Basic net card passthrough libvirt selftest Thanks Zhenzhong [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KFYU… Zhenzhong Duan (3): qemu: Introduce scalable_mode and first_stage capabilities conf: add support for 'scalable_mode' and 'first_stage' attributes to intel IOMMU qemu: Add command line support for scalable mode and first stage of virtual vtd docs/formatdomain.rst | 8 +++++ src/conf/domain_conf.c | 35 ++++++++++++++++++- src/conf/domain_conf.h | 2 ++ src/conf/domain_validate.c | 6 ++++ src/conf/schemas/domaincommon.rng | 10 ++++++ src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 2 ++ src/qemu/qemu_command.c | 2 ++ src/qemu/qemu_validate.c | 12 +++++++ .../caps_10.0.0_x86_64+amdsev.xml | 2 ++ .../caps_10.0.0_x86_64.xml | 2 ++ .../caps_10.1.0_x86_64+inteltdx.xml | 2 ++ .../caps_10.1.0_x86_64.xml | 2 ++ .../caps_10.2.0_x86_64.xml | 2 ++ .../caps_6.2.0_x86_64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../caps_7.1.0_x86_64.xml | 1 + .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + 26 files changed, 102 insertions(+), 1 deletion(-) -- 2.47.3

3 6

[PATCH] hw/riscv: Remove deprecated 'riscv,delegate' device-tree property
by Philippe Mathieu-Daudé 05 Mar '26

05 Mar '26

The "riscv,delegate" DT property was added in QEMU 7.0 as part of the AIA APLIC support. The property changed name during the review process in Linux and the correct name ended up being "riscv,delegation". The incorrect name was added as alias, and deprecated in v9.1 (commit 38facfa8432), so can be removed for v11.0. Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org> --- Binary file pc-bios/opensbi-riscv32-generic-fw_dynamic.bin matches Binary file pc-bios/opensbi-riscv64-generic-fw_dynamic.bin matches --- docs/about/deprecated.rst | 11 ----------- docs/about/removed-features.rst | 11 +++++++++++ hw/riscv/virt.c | 9 --------- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 1d5c4f3707c..cc5502e5394 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -494,17 +494,6 @@ versions, aliases will point to newer CPU model versions depending on the machine type, so management software must resolve CPU model aliases before starting a virtual machine. -RISC-V "virt" board "riscv,delegate" DT property (since 9.1) -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' - -The "riscv,delegate" DT property was added in QEMU 7.0 as part of -the AIA APLIC support. The property changed name during the review -process in Linux and the correct name ended up being -"riscv,delegation". Changing the DT property name will break all -available firmwares that are using the current (wrong) name. The -property is kept as is in 9.1, together with "riscv,delegation", to -give more time for firmware developers to change their code. - x86 "isapc" board use of modern x86 CPUs (since 10.2) ''''''''''''''''''''''''''''''''''''''''''''''''''''' diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst index 41bec8b8e38..0a62e87ee35 100644 --- a/docs/about/removed-features.rst +++ b/docs/about/removed-features.rst @@ -1232,6 +1232,17 @@ converting to using TCG plugins they should contact the qemu-devel mailing list. +Firmware, ACPI, Device Tree +--------------------------- + +RISC-V "virt" board "riscv,delegate" DT property (removed in 11.0) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +The "riscv,delegate" DT property was added in QEMU 7.0 as part of +the AIA APLIC support. The property changed name during the review +process in Linux and the correct name ended up being "riscv,delegation". + + System emulator devices ----------------------- diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index bbce2fb6671..a1c323e66df 100644 --- a/hw/riscv/virt.c +++ b/hw/riscv/virt.c @@ -666,15 +666,6 @@ static void create_fdt_one_aplic(RISCVVirtState *s, int socket, qemu_fdt_setprop_cells(ms->fdt, aplic_name, "riscv,delegation", aplic_child_phandle, 0x1, VIRT_IRQCHIP_NUM_SOURCES); - /* - * DEPRECATED_9.1: Compat property kept temporarily - * to allow old firmwares to work with AIA. Do *not* - * use 'riscv,delegate' in new code: use - * 'riscv,delegation' instead. - */ - qemu_fdt_setprop_cells(ms->fdt, aplic_name, "riscv,delegate", - aplic_child_phandle, 0x1, - VIRT_IRQCHIP_NUM_SOURCES); } riscv_socket_fdt_write_id(ms, aplic_name, socket); -- 2.52.0

4 4

[PATCH 1/2] hyperv: improve error message when redefining domain
by Jonathon Jongsma 04 Mar '26

04 Mar '26

The current error message results in something like the following when running `virsh define` for an existing domain: `domain Domain already exists with UUID '$UUID' exists already` Improve the error message and make it behave like the esx driver and indicate that we do not yet support redefining existing domains in hyperv. Also avoid using the public LookupByUUID() API to check for existance, which requires unnecessarily allocating and de-allocating a virDomainPtr object. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- src/hyperv/hyperv_driver.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/hyperv/hyperv_driver.c b/src/hyperv/hyperv_driver.c index b01b4919fe..6e9917f92a 100644 --- a/src/hyperv/hyperv_driver.c +++ b/src/hyperv/hyperv_driver.c @@ -2933,6 +2933,8 @@ hypervDomainDefineXML(virConnectPtr conn, const char *xml) virDomainPtr domain = NULL; g_autoptr(hypervInvokeParamsList) params = NULL; g_autoptr(GHashTable) defineSystemParam = NULL; + g_autoptr(Msvm_ComputerSystem) existing = NULL; + char uuid_string[VIR_UUID_STRING_BUFLEN]; size_t i = 0; /* parse xml */ @@ -2943,13 +2945,10 @@ hypervDomainDefineXML(virConnectPtr conn, const char *xml) goto error; /* abort if a domain with this UUID already exists */ - if ((domain = hypervDomainLookupByUUID(conn, def->uuid))) { - char uuid_string[VIR_UUID_STRING_BUFLEN]; - virUUIDFormat(domain->uuid, uuid_string); - virReportError(VIR_ERR_DOM_EXIST, _("Domain already exists with UUID '%1$s'"), uuid_string); - - // Don't use the 'exit' label, since we don't want to delete the existing domain. - virObjectUnref(domain); + virUUIDFormat(def->uuid, uuid_string); + if (hypervMsvmComputerSystemFromUUID(priv, uuid_string, &existing) == 0 && existing != NULL) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("Domain already exists, editing existing domains is not supported yet")); return NULL; } -- 2.53.0

3 4

[RFC 0/2] Fix build with libvirtd disabled
by Jim Fehlig 03 Mar '26

03 Mar '26

I'm considering dropping the monolithic libvirtd in future versions of SUSE distros, which got me to checking the usability of -Ddriver_libvirtd=disabled. I found it's not very usable :-). This series if an RFC attempt to rectify the situation. I'm not sure if we should build the various "common" components unconditionally as this change does, or only if the monolithic libvirtd and/or one or more modular daemons are also being built. Thanks for any comments! Jim Fehlig (2): build: Fix build with libvirtd disabled spec: Add option to enable/disable libvirtd docs/manpages/meson.build | 10 +- libvirt.spec.in | 25 +++- meson.build | 209 +++++++++++++--------------- meson_options.txt | 14 +- src/access/meson.build | 3 - src/locking/meson.build | 281 +++++++++++++++++++------------------- src/logging/meson.build | 104 +++++++------- src/meson.build | 200 +++++++++++++-------------- src/remote/meson.build | 174 +++++++++++------------ src/security/meson.build | 2 +- src/util/meson.build | 24 ++-- tools/meson.build | 26 ++-- 12 files changed, 526 insertions(+), 546 deletions(-) -- 2.51.0

3 5

[PULL 02/18] deprecation: don't enable TCG plugins by default with TCI
by Alex Bennée 27 Feb '26

27 Feb '26

The softmmu memory instrumentation test sees so many more accesses than a normal translated host and its really not worth fixing up. Lets deprecate this odd configuration and save on the CI cycles. Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> Message-Id: <20240916085400.1046925-3-alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 809b2b9b81..c0aa52def5 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -196,6 +196,14 @@ benefits from having plenty of host memory it seems reasonable to encourage users to use 64 bit builds of QEMU for analysis work whatever targets they are instrumenting. +TCG Plugin support not enabled by default with TCI (since 9.2) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +While the TCG interpreter can interpret the TCG ops used by plugins it +is going to be so much slower it wouldn't make sense for any serious +instrumentation. Due to implementation differences there will also be +anomalies in things like memory instrumentation. + System emulator CPUs -------------------- diff --git a/configure b/configure index cc8e1ed5b8..aa7aae70fa 100755 --- a/configure +++ b/configure @@ -629,6 +629,9 @@ meson_option_parse() { exit 1 fi } +has_meson_option() { + test "${meson_options#*"$1"}" != "$meson_options" +} meson_add_machine_file() { if test "$cross_compile" = "yes"; then @@ -1048,8 +1051,12 @@ if test "$static" = "yes" ; then plugins="no" fi if test "$plugins" != "no" && test $host_bits -eq 64; then - plugins=yes - subdirs="$subdirs contrib/plugins" + if has_meson_option "-Dtcg_interpreter=true"; then + plugins="no" + else + plugins=yes + subdirs="$subdirs contrib/plugins" + fi fi cat > $TMPC << EOF -- 2.39.5

2 1