July 2026 - Devel - libvirt List Archives

[PATCH] qemu: Pass driver to qemuDomainRestoreInternal explicitly
by Daniel Golle 13 Aug '26

13 Aug '26

qemuAutostartDomain() starts domains with conn=NULL as there is no client connection during driver initialisation. Since the managed save restore path of qemuDomainObjStart() was switched to qemuDomainRestoreInternal(), which obtains the driver by dereferencing conn->privateData, any domain with both a managed save image and the autostart (or autostart-once) flag crashes virtqemud/libvirtd with SIGSEGV on daemon startup. The session daemon's auto-shutdown feature creates exactly this combination on logout with a running VM (auto_shutdown_try_save saves the domain and auto_shutdown_restore marks it autostart-once), so the first daemon start of every subsequent boot segfaults and clients such as GNOME Boxes fail with "Cannot recv data: Connection reset by peer", showing an empty machine list. Pass the driver as an explicit parameter, as qemuDomainObjRestore() did before it was merged into qemuDomainRestoreInternal(), and keep @conn only for use by the ACL check callbacks, which are not used in the autostart code path. Fixes: 0e2ab427782c ("qemu: driver: Merge 'qemuDomainRestoreInternal' and 'qemuDomainObjRestore'") Signed-off-by: Daniel Golle <daniel(a)makrotopia.org> --- Observed with libvirt 12.5.0 and QEMU 11.0.2 on Arch Linux; the code in current git master is identical. Reproducer (any session domain, regular autostart takes the same path): $ virsh -c qemu:///session managedsave DOMAIN $ virsh -c qemu:///session autostart DOMAIN --once # simulate the first daemon start of a boot: $ rm "$XDG_RUNTIME_DIR/libvirt/qemu/run/autostarted" $ pkill -x virtqemud $ virsh -c qemu:///session list --all error: failed to connect to the hypervisor error: Cannot recv data: Connection reset by peer Backtrace of the crashing thread (12.5.0, distro debug symbols): #0 qemuDomainRestoreInternal (conn=conn@entry=0x0, ...) at ../src/qemu/qemu_driver.c:5940 #1 qemuDomainObjStart.constprop.0 (conn=conn@entry=0x0, ...) at ../src/qemu/qemu_driver.c:6509 #2 qemuAutostartDomain at ../src/qemu/qemu_driver.c:185 #3 virDomainDriverAutoStartOne at ../src/hypervisor/domain_driver.c:700 #7 virDomainDriverAutoStart at ../src/hypervisor/domain_driver.c:728 #8 qemuStateInitialize at ../src/qemu/qemu_driver.c:962 #9 virStateInitialize at ../src/libvirt.c:667 Tested on current master in an isolated session environment with a minimal diskless domain: unpatched, the daemon reproducibly segfaults on startup after the steps above; patched, it starts cleanly and restores the domain from its managed save image. The explicit restore APIs (virDomainRestore*) behave as before. src/qemu/qemu_driver.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 3d57de38..d478d383 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5901,7 +5901,8 @@ qemuNodeGetSecurityModel(virConnectPtr conn, /** * qemuDomainRestoreInternal: - * @conn: connection object + * @driver: QEMU driver + * @conn: connection object (optional if @ensureACL is NULL) * @vmRestore: Domain object (optional; see below) * @path: path to the save image file * @unlink_corrupt: remove corrupted save image file @path @@ -5926,7 +5927,8 @@ qemuNodeGetSecurityModel(virConnectPtr conn, * corrupted image was removed 1 is returned. */ static int -qemuDomainRestoreInternal(virConnectPtr conn, +qemuDomainRestoreInternal(virQEMUDriver *driver, + virConnectPtr conn, virDomainObj *vmRestore, const char *path, bool unlink_corrupt, @@ -5937,7 +5939,6 @@ qemuDomainRestoreInternal(virConnectPtr conn, int (*ensureACL)(virConnectPtr, virDomainDef *), virDomainAsyncJob asyncJob) { - virQEMUDriver *driver = conn->privateData; qemuDomainObjPrivate *priv = NULL; g_autoptr(virDomainDef) def = NULL; virDomainObj *vm = NULL; @@ -6096,7 +6097,8 @@ qemuDomainRestoreFlags(virConnectPtr conn, { virCheckFlags(QEMU_DOMAIN_RESTORE_FLAGS, -1); - return qemuDomainRestoreInternal(conn, NULL, path, false, dxml, NULL, 0, + return qemuDomainRestoreInternal(conn->privateData, conn, NULL, path, + false, dxml, NULL, 0, flags, virDomainRestoreFlagsEnsureACL, VIR_ASYNC_JOB_START); } @@ -6105,7 +6107,8 @@ static int qemuDomainRestore(virConnectPtr conn, const char *path) { - return qemuDomainRestoreInternal(conn, NULL, path, false, NULL, NULL, 0, + return qemuDomainRestoreInternal(conn->privateData, conn, NULL, path, + false, NULL, NULL, 0, 0, virDomainRestoreEnsureACL, VIR_ASYNC_JOB_START); } @@ -6141,7 +6144,8 @@ qemuDomainRestoreParams(virConnectPtr conn, return -1; } - ret = qemuDomainRestoreInternal(conn, NULL, path, false, dxml, params, nparams, + ret = qemuDomainRestoreInternal(conn->privateData, conn, NULL, path, + false, dxml, params, nparams, flags, virDomainRestoreParamsEnsureACL, VIR_ASYNC_JOB_START); return ret; @@ -6506,7 +6510,7 @@ qemuDomainObjStart(virConnectPtr conn, restore_flags |= bypass_cache ? VIR_DOMAIN_SAVE_BYPASS_CACHE : 0; restore_flags |= reset_nvram ? VIR_DOMAIN_SAVE_RESET_NVRAM : 0; - ret = qemuDomainRestoreInternal(conn, vm, managed_save, true, NULL, NULL, 0, + ret = qemuDomainRestoreInternal(driver, conn, vm, managed_save, true, NULL, NULL, 0, restore_flags, NULL, asyncJob); -- 2.55.0

2 1

[PATCH 1/1] remote: fix stale status snapshot in daemonStreamHandleWrite
by Denis V. Lunev 13 Aug '26

13 Aug '26

daemonStreamHandleWrite() snapshots status from msg->header.status before dispatching to the per-type handler, then reuses that stale snapshot afterwards to decide whether to send a fake release reply. A stale snapshot lets it send that reply twice for the same 'msg', linking the message to itself and deadlooping the event loop thread in virNetMessageQueuePush()'s tail-walk loop. Remove the 'status' variable and read msg->header.status directly at the point of use instead. Commit 411cbe7199c ("remote: fix stream use-after-free") introduced it alongside its real fix: it also moved virNetMessageQueueServe() to dequeue 'msg' from stream->rx before dispatch instead of after, which is what actually prevents corrupting stream->rx's linkage and remains unchanged here. The variable itself was never load-bearing: no dispatch handler frees 'msg' on the path that reaches this check, so reading msg->header.status straight from 'msg' cannot go stale. Fixes: 411cbe7199ce ("remote: fix stream use-after-free") Signed-off-by: Denis V. Lunev <den(a)openvz.org> --- src/remote/remote_daemon_stream.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 3777c8e684..437cec374f 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -736,7 +736,6 @@ static int daemonStreamHandleWrite(virNetServerClient *client, daemonClientStream *stream) { - virNetMessageStatus status = VIR_NET_OK; VIR_DEBUG("client=%p, stream=%p", client, stream); while (stream->rx && !stream->closed) { @@ -748,10 +747,8 @@ daemonStreamHandleWrite(virNetServerClient *client, * Otherwise just carry on with processing stream * data. */ ret = daemonStreamHandleHole(client, stream, msg); - status = msg->header.status; } else if (msg->header.type == VIR_NET_STREAM) { - status = msg->header.status; - switch (status) { + switch (msg->header.status) { case VIR_NET_OK: ret = daemonStreamHandleFinish(client, stream, msg); break; @@ -791,7 +788,7 @@ daemonStreamHandleWrite(virNetServerClient *client, * onto the wire, but this causes the client to reset * its active request count / throttling */ - if (status == VIR_NET_CONTINUE) { + if (msg->header.status == VIR_NET_CONTINUE) { virNetMessageClear(msg); msg->header.type = VIR_NET_REPLY; if (virNetServerClientSendMessage(client, msg) < 0) { -- 2.53.0

4 6

[PATCH 0/3] bhyve: implement virDomainSetLifecycleAction() API
by Roman Bogorodskiy 13 Aug '26

13 Aug '26

Roman Bogorodskiy (3): bhyve: add validation for lifecycle actions bhyve: monitor: respect on_poweroff / on_reboot settings bhyve: implement virDomainSetLifecycleAction() API src/bhyve/bhyve_domain.c | 36 +++++++++++++ src/bhyve/bhyve_domain.h | 3 ++ src/bhyve/bhyve_driver.c | 110 ++++++++++++++++++++++++++++++++++++++ src/bhyve/bhyve_monitor.c | 20 +++++-- 4 files changed, 165 insertions(+), 4 deletions(-) -- 2.52.0

2 5

[PATCH] FreeBSD: set cpu_freq to zero if cannot read value
by Tiago Espinha Gasiba 12 Aug '26

12 Aug '26

From: Tiago Gasiba <tiago.gasiba(a)gmail.com> From: Tiago Gasiba <tiga(a)FreeBSD.org> Signed-off-by: Tiago Espinha Gasiba <tiago.gasiba(a)gmail.com> --- src/util/virhostcpu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index f2b25e940b..b602592fb7 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -993,8 +993,8 @@ virHostCPUGetInfo(virArch hostarch G_GNUC_UNUSED, if (sysctlbyname("dev.cpu.0.freq", &cpu_freq, &cpu_freq_len, NULL, 0) < 0) { if (sysctlbyname("hw.clockrate", &cpu_freq, &cpu_freq_len, NULL, 0) < 0) { - virReportSystemError(errno, "%s", _("cannot obtain CPU freq")); - return -1; + VIR_WARN("cannot obtain CPU freq, setting to 0"); + cpu_freq = 0; } } -- 2.50.1 (Apple Git-155)

3 2

[PATCH v8 0/4] nwfilter: add nwfilter nftables driver
by Dion Bosschieter 11 Aug '26

11 Aug '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 third patch introduces unit testing of the new nftables driver. Finally the last patch introduces a new element to the nwfilterbinding XML which is used to detect and run a cleanup on the old firewall rules defined via the previous used nwfilter firewall backend. - Implemented very basic nwfilter.conf reading, 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. - Implemented nft tracing and counters usable via nwfilter.conf options "enable_trace" and "enable_counters" - Resolves issue https://gitlab.com/libvirt/libvirt/-/issues/603, benchmarks showed that the amount of iifname jumps for each interface in the root chains 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 patch 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 the performance degradation, the vmap instead solves this. - Split rules into separate tables: "libvirt_nwfilter_ethernet" and "libvirt_nwfilter_inet" 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 _inet 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 inet rules in seperate tables "libvirt_nwfilter_ethernet" and "libvirt_nwfilter_inet". - 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 _inet 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): - 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 v8: - Fix incompatibility issue with ebiptables driver for inet rules Inet rules in nftables are now placed on the root chains following iptables logic inside the ebiptables driver. Introducing subchains for inet caused sorting problems, subchains can accept or drop a packet which on the ebiptables driver inet rules would have been filtered out by rules that were sorted differently. Changes in v7: - Add backend XML element to virnwfilterbinding, to support switching from nwfilter firewall backend Changes in v6: - Add STP support - Add GARP support - Remove comment "priority=%" leftover from debugging 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 (4): 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 nwfilter: add used firewall backend to nwfilterbinding libvirt.spec.in | 7 + po/POTFILES | 2 + src/conf/schemas/nwfilterbinding.rng | 7 + src/conf/virnwfilterbindingdef.c | 17 +- src/conf/virnwfilterbindingdef.h | 1 + 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 | 67 +- 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 | 144 +- src/nwfilter/nwfilter_gentech_driver.h | 5 +- src/nwfilter/nwfilter_nftables_driver.c | 2864 +++++++++++++ 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 | 298 ++ .../ah-linux.nftables.args | 292 ++ .../all-ipv6-linux.nftables.args | 280 ++ .../all-linux.nftables.args | 274 ++ .../arp-linux.nftables.args | 285 ++ .../comment-linux.nftables.args | 502 +++ .../conntrack-linux.nftables.args | 190 + .../esp-ipv6-linux.nftables.args | 298 ++ .../esp-linux.nftables.args | 292 ++ .../example-1-linux.nftables.args | 252 ++ .../example-2-linux.nftables.args | 352 ++ .../hex-data-linux.nftables.args | 368 ++ .../icmp-direction-linux.nftables.args | 226 ++ .../icmp-direction2-linux.nftables.args | 226 ++ .../icmp-direction3-linux.nftables.args | 176 + .../icmp-linux.nftables.args | 248 ++ .../icmpv6-linux.nftables.args | 316 ++ .../igmp-linux.nftables.args | 292 ++ .../ip-linux.nftables.args | 199 + .../ipt-no-macspoof-linux.nftables.args | 166 + .../ipv6-linux.nftables.args | 481 +++ .../iter1-linux.nftables.args | 292 ++ .../iter2-linux.nftables.args | 3532 +++++++++++++++++ .../iter3-linux.nftables.args | 410 ++ .../mac-linux.nftables.args | 176 + .../rarp-linux.nftables.args | 207 + .../sctp-ipv6-linux.nftables.args | 316 ++ .../sctp-linux.nftables.args | 316 ++ .../stp-linux.nftables.args | 233 ++ .../target-linux.nftables.args | 454 +++ .../target2-linux.nftables.args | 302 ++ .../tcp-ipv6-linux.nftables.args | 316 ++ .../tcp-linux.nftables.args | 452 +++ .../udp-ipv6-linux.nftables.args | 316 ++ .../udp-linux.nftables.args | 316 ++ .../udplite-ipv6-linux.nftables.args | 298 ++ .../udplite-linux.nftables.args | 292 ++ .../vlan-linux.nftables.args | 257 ++ tests/nwfilterxml2nftfirewalltest.c | 432 ++ .../filter-vars.xml | 1 + .../simple-backend.xml | 10 + tests/virnwfilterbindingxml2xmltest.c | 1 + 64 files changed, 18845 insertions(+), 119 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 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 100644 tests/nwfilterxml2firewalldata/stp-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 100644 tests/nwfilterxml2nftfirewalltest.c create mode 100644 tests/virnwfilterbindingxml2xmldata/simple-backend.xml -- 2.43.0

3 9

[PATCH v10 0/6] qemu: Support HW-accelerated vSMMUs
by Nathan Chen 05 Aug '26

05 Aug '26

Hi, This is a follow up to the v9 patchset [0] for supporting multiple hardware-accelerated vSMMU instances. 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> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver pciBus='1' accel='on' ats='on' ril='off' ssidsize='20' oas='44'/> </iommu> <iommu model='smmuv3'> <driver pciBus='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":"on","ril":"off","ssidsize":"20","oas":"44"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":"on","ril":"off","ssidsize":"20","oas":"44"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","bus":"pci.22","addr":"0x0"}' \ Two QEMU series implementing auto support for accel SMMUv3 properties are now present in the upstream master branch [1][2]. This Libvirt series leverages the auto support: users can omit SMMUv3 properties ATS, RIL, OAS, and SSIDSIZE on the domain XML, and they will also be omitted on the QEMU command line as a result. With these new QEMU series applied, the feature property values will default to 'auto' to be resolved based on what the host SMMU supports. This series also adds documentation fixes for docs/formatdomain.rst and implements support for QEMU capability checks on device-pluggable accel smmuv3. This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3-accel-v10/ Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/W6HJ… [1] https://lore.kernel.org/all/20260323182454.1416110-1-nathanc@nvidia.com/ [2] https://lore.kernel.org/all/20260608174900.2227340-1-nathanc@nvidia.com/ Changes from v9: - Rename ssidSize to ssidsize - Update docs/formatdomain.rst to mention `since 12.6.0` for accel smmuv3 properties and these properties' hypervisor defaults being used if not specified. - Separate out virDomainIOMMUDefEquals() check for pci_bus into a new fix commit - Include fix commit for `since 11.10.0` for pciBus attribute in docs/formatdomain.rst - Use T:accel to propagate accel=off - Use qemuOnOffAuto() for ats and ril - Add QEMU capabilities checks for device-pluggable smmuv3 and accel smmuv3 Changes from v8: - Changed smmuv3 attribute QEMU CLI values to strings to match QEMU 11.0 Changes from v7: - Remove support for x-vpasid-cap-offset based on feedback pointing out the QEMU feature prefixed with x- is experimental and not to be supported in Libvirt - Implement support for auto SMMUv3 properties. Omitting these properties in the XML omits them on the QEMU command line as well, which results in default auto values being chosen for ATS, RIL, SSIDSIZE, and OAS - Add validation check that only allows enabling accel SMMUv3 features when accel is enabled - Add tests for accel=on but omitting accel SMMUv3 feature properties 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) Nathan Chen (6): conf: Include check for pci_bus in virDomainIOMMUDefEquals() docs: formatdomain: Include Libvirt version for IOMMU pciBus attribute qemu: Add support for HW-accelerated nested SMMUv3 qemu: introduce QEMU_CAPS_ARM_SMMUV3 qemu: introduce QEMU_CAPS_ARM_SMMUV3_ACCEL tests: qemuxmlconfdata: provide HW-accel smmuv3 sample XML and CLI args docs/formatdomain.rst | 41 ++++- src/conf/domain_conf.c | 80 ++++++++++ src/conf/domain_conf.h | 5 + src/conf/domain_validate.c | 27 +++- src/conf/schemas/domaincommon.rng | 25 +++ src/qemu/qemu_capabilities.c | 14 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 15 ++ src/qemu/qemu_validate.c | 21 ++- .../caps_10.0.0_aarch64.replies | 79 ++++++---- .../caps_10.2.0_aarch64.replies | 89 +++++++---- .../caps_10.2.0_aarch64.xml | 1 + .../caps_11.0.0_aarch64.replies | 132 ++++++++++++---- .../caps_11.0.0_aarch64.xml | 2 + .../caps_11.1.0_aarch64.replies | 143 ++++++++++++++---- .../caps_11.1.0_aarch64.xml | 2 + .../caps_8.2.0_aarch64.replies | 79 ++++++---- .../caps_8.2.0_armv7l.replies | 79 ++++++---- .../caps_9.2.0_aarch64+hvf.replies | 75 ++++++--- ...uv3-pci-bus-accel-auto.aarch64-latest.args | 38 +++++ ...muv3-pci-bus-accel-auto.aarch64-latest.xml | 63 ++++++++ .../iommu-smmuv3-pci-bus-accel-auto.xml | 53 +++++++ ...u-smmuv3-pci-bus-accel.aarch64-latest.args | 38 +++++ ...mu-smmuv3-pci-bus-accel.aarch64-latest.xml | 63 ++++++++ .../iommu-smmuv3-pci-bus-accel.xml | 53 +++++++ tests/qemuxmlconftest.c | 2 + 26 files changed, 1032 insertions(+), 189 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel-auto.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel-auto.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel-auto.xml 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 13

[RFC PATCH v2 0/5] Arm CPU features with supported values
by sandesh.patel＠nutanix.com 05 Aug '26

05 Aug '26

From: Sandesh Patel <sandesh.patel(a)nutanix.com> Hi, This RFC series adds libvirt support for ARM CPU features that are exposed by QEMU as multi-valued properties, rather than the on/off booleans we are used to from x86. Background ========== On ARM, several CPU properties can take one of a small set of values (e.g. "0.0", "1.0", "1.1_base", "off"), and the set of values supported by each property is host-specific. This cannot be expressed using libvirt's existing boolean feature model. This series depends on a pending QEMU RFC [1] that introduces non-boolean feature handling for ARM CPUs. That series also adds a new QMP command, query-arm-cpu-props-info, which reports the values the host accelerator supports for each ARM CPU property. Example reply fragment: { "name": "hw_prop_WRPs", "supported-values": ["0-3"], "type": "number" } On top of that QEMU work, this libvirt RFC wires up the end-to-end flow: probing the host, caching the probed information, exposing the values in the guest CPU XML, and passing them through to the QEMU -cpu command line. I am posting this as an RFC primarily to get maintainer feedback on the overall approach before investing in the missing pieces (in particular, value validation, which is intentionally not yet implemented). See "Open questions" below. Overview of the series ====================== 1. Add a QMP wrapper for query-arm-cpu-props-info, a new QEMU_CAPS_QUERY_ARM_CPU_PROPS_INFO capability bit, and the qemuMonitorCPUPropsInfoList data structure. The command is issued on ARM + KVM hosts and the reply is stored in the per-accelerator capabilities. 2. Persist the probed list into the on-disk QEMU capabilities cache as <cpuPropertyInfo>, so that subsequent libvirtd restarts do not need to re-issue the QMP query. 3. Extend the guest CPU XML with an optional 'value' attribute on <feature>: <cpu mode='host-passthrough'> <feature policy='require' name='feat_RAS' value='1.0'/> <feature policy='require' name='hw_prop_API' value='off'/> <feature policy='require' name='hw_prop_WRPs' value='2'/> </cpu> When a feature carries a non-NULL 'value', libvirt emits '<name>=<value>' on the QEMU -cpu command line; in that case the policy must be 'require' or 'force'. The existing policy-driven '=on' / '=off' path is used only for features without an explicit value. All ARM property names returned by query-arm-cpu-props-info are registered in src/cpu_map/arm_features.xml so that the guest XML parser and validator accept them. With this change, the generated QEMU command line can look like: -cpu host-passthrough,hw_prop_API=off,hw_prop_WRPs=2 Changes since v1: ================ - Split the single "query" patch so the new capability bit is added in its own patch, separate from the code that uses it. - The capability dump is now captured from a real QEMU (built with the pending ARM series and probed with qemucapsprobe on a KVM host) instead of being edited by hand. It is added as a separate "+armcpuprops" variant Open questions ============== - Value validation: should libvirt validate the requested value against the host's supported-values list at define time, at start time, or defer entirely to QEMU? - Policy vs. value conflicts: is requiring policy='require' / 'force' whenever 'value' is set the right rule? - Caching location: is the per-accelerator QEMU capabilities cache the right place to store the probed property list, or should this live alongside the CPU model data in cpu_map? Sandesh Patel (5): Add QEMU_CAPS_QUERY_ARM_CPU_PROPS_INFO Add support to query ARM CPU property values Cache and load ARM CPU property information Add '+armcpuprops' capability variant for query-arm-cpu-props-info QMP Support 'value' attribute on CPU features src/conf/cpu_conf.c | 21 +- src/conf/cpu_conf.h | 1 + src/conf/schemas/cputypes.rng | 5 + src/cpu_map/arm_features.xml | 171 + src/qemu/qemu_capabilities.c | 130 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 + src/qemu/qemu_monitor.c | 52 + src/qemu/qemu_monitor.h | 26 + src/qemu/qemu_monitor_json.c | 66 + src/qemu/qemu_monitor_json.h | 5 + .../qemu_11.1.0-virt.aarch64+armcpuprops.xml | 357 + .../qemu_11.1.0.aarch64+armcpuprops.xml | 357 + .../caps_11.1.0_aarch64+armcpuprops.replies | 40506 ++++++++++++++++ .../caps_11.1.0_aarch64+armcpuprops.xml | 1436 + .../caps.aarch64+armcpuprops.xml | 28 + tests/qemumonitorjsontest.c | 91 + ...res-values.aarch64-latest+armcpuprops.args | 34 + ...ures-values.aarch64-latest+armcpuprops.xml | 46 + .../aarch64-cpu-features-values.xml | 30 + tests/qemuxmlconftest.c | 2 + tests/testutilshostcpus.h | 74 +- 22 files changed, 43411 insertions(+), 41 deletions(-) create mode 100644 tests/domaincapsdata/qemu_11.1.0-virt.aarch64+armcpuprops.xml create mode 100644 tests/domaincapsdata/qemu_11.1.0.aarch64+armcpuprops.xml create mode 100644 tests/qemucapabilitiesdata/caps_11.1.0_aarch64+armcpuprops.replies create mode 100644 tests/qemucapabilitiesdata/caps_11.1.0_aarch64+armcpuprops.xml create mode 100644 tests/qemucaps2xmloutdata/caps.aarch64+armcpuprops.xml create mode 100644 tests/qemuxmlconfdata/aarch64-cpu-features-values.aarch64-latest+armcpuprops.args create mode 100644 tests/qemuxmlconfdata/aarch64-cpu-features-values.aarch64-latest+armcpuprops.xml create mode 100644 tests/qemuxmlconfdata/aarch64-cpu-features-values.xml -- 2.43.7

2 7

[PATCH 0/2] Properly handle tri-state for KVM options
by Chris Riches 03 Aug '26

03 Aug '26

Two of the qemu kvm_features (kvm-poll-control and kvm-pv-ipi) were only emitted when on or when off respectively, rather than handling the full tri-state for each (on, off, absent). This meant that config like <poll-control state='off'/> was a no-op, equivalent to not specifying poll-control at all, which fails to prevent QEMU from enabling it based on its own internal defaults. In particular, this meant that having both <cpu mode='host-passthrough'> and <poll-control state='off'/> would cause the latter to be ignored, since libvirt would emit no explicit kvm-poll-control arg, and QEMU defaults to enabling most KVM features when CPU passthrough is enabled. Fix these two cases such that explicit on/off are both respected. The `hidden` and `hint-dedicated` options are left as-is, since these really do only make sense in the `on` direction; QEMU will never automatically enable them. Chris Riches (2): qemu: Emit explicit kvm-poll-control=off when disabled qemu: Emit explicit kvm-pv-ipi=on when enabled src/qemu/qemu_command.c | 14 ++++++++++---- .../kvm-features-off.x86_64-latest.args | 2 +- .../kvm-features.x86_64-latest.args | 2 +- 3 files changed, 12 insertions(+), 6 deletions(-) -- 2.43.0

2 7

[PATCH] bhyve: capabilities: use full path for emulator
by Roman Bogorodskiy 03 Aug '26

03 Aug '26

Currently, when the bhyve driver builds capabilities, it uses just "bhyve" as emulator path. That leads to issues, e.g. virt-manager uses this value to fill domain's emulator field, which has to be an absolute path. So that results in a domain XML that fails validation. Fix by trying to find "bhyve" in PATH and falling back to "/usr/sbin/bhyve". Closes: https://gitlab.com/libvirt/libvirt/-/work_items/899 Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_capabilities.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/bhyve/bhyve_capabilities.c b/src/bhyve/bhyve_capabilities.c index 1fe0a3ad77..85988a2ce8 100644 --- a/src/bhyve/bhyve_capabilities.c +++ b/src/bhyve/bhyve_capabilities.c @@ -48,13 +48,14 @@ virBhyveCapsBuild(void) virCaps *caps; virCapsGuest *guest; virArch hostarch = virArchFromHost(); + g_autofree char *binary = virFindFileInPath("bhyve"); if ((caps = virCapabilitiesNew(hostarch, false, false)) == NULL) return NULL; guest = virCapabilitiesAddGuest(caps, VIR_DOMAIN_OSTYPE_HVM, - hostarch, "bhyve", + hostarch, binary ? binary : "/usr/sbin/bhyve", NULL, 0, NULL); virCapabilitiesAddGuestDomain(guest, VIR_DOMAIN_VIRT_BHYVE, -- 2.52.0

3 3

Entering freeze for libvirt-12.6.0
by Jiri Denemark 30 Jul '26

30 Jul '26

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

1 1