- Devel - libvirt List Archives

[PATCH] bhyve: restore persistent definition after process stop
by Roman Bogorodskiy 10 Aug '26

10 Aug '26

The virBhyveProcessStop() function which handles bhyve process shutdown does not remove the transient definition, meaning that it overrides the persistent definition. Update it to call virDomainObjRemoveTransientDef(). Also, move the body of the code to virBhyveProcessStopImpl() which accepts 'restoreDef' argument telling whether the transient definition should be removed. That is necessary as reboot is implemented as stop + start, and in this case the transient definition should not be removed. Closes: https://gitlab.com/libvirt/libvirt/-/work_items/900 Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_process.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c index 81f00954c2..65e3bdfd02 100644 --- a/src/bhyve/bhyve_process.c +++ b/src/bhyve/bhyve_process.c @@ -630,6 +630,7 @@ bhyveProcessRemoveDomainStatus(const char *statusDir, * @vm: domain object * @reason: shutoff reason * @forceCleanup: boolean controlling cleanup + * @restoreDef: whether to restore the persistent definition after cleanup * * Stops the domain and cleans up its resources. * It could be used whether as a direct call or as a cleanup routine. @@ -641,11 +642,12 @@ bhyveProcessRemoveDomainStatus(const char *statusDir, * * Returns 0 on success, -1 on error. */ -int -virBhyveProcessStop(struct _bhyveConn *driver, - virDomainObj *vm, - virDomainShutoffReason reason, - bool forceCleanup) +static int +virBhyveProcessStopImpl(struct _bhyveConn *driver, + virDomainObj *vm, + virDomainShutoffReason reason, + bool forceCleanup, + bool restoreDef) { int ret = 0; size_t i = 0; @@ -724,9 +726,21 @@ virBhyveProcessStop(struct _bhyveConn *driver, virPidFileDelete(BHYVE_STATE_DIR, vm->def->name); bhyveProcessRemoveDomainStatus(BHYVE_STATE_DIR, vm->def->name); + if (restoreDef) + virDomainObjRemoveTransientDef(vm); + return ret; } +int +virBhyveProcessStop(struct _bhyveConn *driver, + virDomainObj *vm, + virDomainShutoffReason reason, + bool forceCleanup) +{ + return virBhyveProcessStopImpl(driver, vm, reason, forceCleanup, true); +} + int virBhyveProcessShutdown(virDomainObj *vm) { @@ -754,7 +768,8 @@ int virBhyveProcessRestart(struct _bhyveConn *driver, virDomainObj *vm) { - if (virBhyveProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN, false) < 0) + if (virBhyveProcessStopImpl(driver, vm, VIR_DOMAIN_SHUTOFF_SHUTDOWN, + false, false) < 0) return -1; if (virBhyveProcessStartImpl(driver, vm, VIR_DOMAIN_RUNNING_BOOTED) < 0) -- 2.52.0

2 1

[PATCH] bhyve: implement virDomainAgentSetResponseTimeout()
by Roman Bogorodskiy 06 Aug '26

06 Aug '26

Implement the virDomainAgentSetResponseTimeout() which allows to set the qemu guest agent timeout. The change consists of two main parts: - bhyveDomainAgentSetResponseTimeout() driver method implementation which actually sets the agent timeout. - Updating virDomainXMLPrivateDataCallbacks with "parse" and "format" methods implementation for parsing and formatting of the agent timeout value in domain's XML. Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_domain.c | 29 +++++++++++++++++++++++++ src/bhyve/bhyve_driver.c | 47 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 76 insertions(+) diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c index b6344185b7..3b5a9b47a3 100644 --- a/src/bhyve/bhyve_domain.c +++ b/src/bhyve/bhyve_domain.c @@ -62,9 +62,38 @@ bhyveDomainObjPrivateFree(void *data) g_free(priv); } +static int +bhyveDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt, + virDomainObj *vm, + virDomainDefParserConfig *config G_GNUC_UNUSED) +{ + bhyveDomainObjPrivate *priv = vm->privateData; + + if (virXPathInt("string(./agentTimeout)", ctxt, &priv->agentTimeout) == -2) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("failed to parse agent timeout")); + return -1; + } + + return 0; +} + +static int +bhyveDomainObjPrivateXMLFormat(virBuffer *buf, + virDomainObj *vm) +{ + bhyveDomainObjPrivate *priv = vm->privateData; + + virBufferAsprintf(buf, "<agentTimeout>%i</agentTimeout>\n", priv->agentTimeout); + + return 0; +} + virDomainXMLPrivateDataCallbacks virBhyveDriverPrivateDataCallbacks = { .alloc = bhyveDomainObjPrivateAlloc, .free = bhyveDomainObjPrivateFree, + .parse = bhyveDomainObjPrivateXMLParse, + .format = bhyveDomainObjPrivateXMLFormat, }; static bool diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index 4abcd70aba..0823b54b0d 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -2808,6 +2808,52 @@ bhyveDomainRename(virDomainPtr domain, return ret; } +static int +bhyveDomainAgentSetResponseTimeout(virDomainPtr domain, + int timeout, + unsigned int flags) +{ + virDomainObj *vm = NULL; + bhyveDomainObjPrivate *priv = NULL; + struct _bhyveConn *privconn = domain->conn->privateData; + int ret = -1; + + virCheckFlags(0, -1); + + if (timeout < VIR_DOMAIN_QEMU_AGENT_COMMAND_MIN) { + virReportError(VIR_ERR_INVALID_ARG, + _("guest agent timeout '%1$d' is less than the minimum '%2$d'"), + timeout, VIR_DOMAIN_QEMU_AGENT_COMMAND_MIN); + return -1; + } + + if (!(vm = bhyveDomObjFromDomain(domain))) + return -1; + + if (virDomainAgentSetResponseTimeoutEnsureACL(domain->conn, vm->def) < 0) + goto cleanup; + + priv = vm->privateData; + if (priv->agent != NULL) { + virObjectLock(priv->agent); + qemuAgentSetResponseTimeout(priv->agent, timeout); + virObjectUnlock(priv->agent); + } + + priv->agentTimeout = timeout; + + if (virDomainObjIsActive(vm)) { + if (virDomainObjSave(vm, privconn->xmlopt, BHYVE_STATE_DIR) < 0) + VIR_WARN("Failed to save status on vm %s", vm->def->name); + } + + ret = 0; + + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + static virHypervisorDriver bhyveHypervisorDriver = { .name = "bhyve", .connectURIProbe = bhyveConnectURIProbe, @@ -2886,6 +2932,7 @@ static virHypervisorDriver bhyveHypervisorDriver = { .domainAuthorizedSSHKeysGet = bhyveDomainAuthorizedSSHKeysGet, /* 12.5.0 */ .domainAuthorizedSSHKeysSet = bhyveDomainAuthorizedSSHKeysSet, /* 12.5.0 */ .domainRename = bhyveDomainRename, /* 12.6.0 */ + .domainAgentSetResponseTimeout = bhyveDomainAgentSetResponseTimeout, /* 12.7.0 */ }; -- 2.52.0

2 1

[PATCH v11 0/7] qemu: Support HW-accelerated vSMMUs
by Nathan Chen 06 Aug '26

06 Aug '26

Hi, This is a follow up to the v10 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-v11/ Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z33Q… [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 v10: - Move QEMU capabilities patches before introducing accel support - Move qemu_validate.c QEMU cap check for accel to the main accel support patch - Use QEMU_CAPS_ARM_SMMUV3_SMMU_PER_BUS instead of QEMU_CAPS_ARM_SMMUV3 - Remove check for qemu reporting arm-smmuv3 support on non-ARM architecture - Revise qemuValidateDomainDeviceDefIOMMU conditional statement format - Add QEMU_CAPS_DEVICE_SMMUV3 and gate QEMU_CAPS_ARM_SMMUV3_SMMU_PER_BUS on QEMU_CAPS_DEVICE_SMMUV3 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 (7): conf: Include check for pci_bus in virDomainIOMMUDefEquals() docs: formatdomain: Include Libvirt version for IOMMU pciBus attribute qemu: introduce QEMU_CAPS_DEVICE_SMMUV3 qemu: introduce QEMU_CAPS_ARM_SMMUV3_SMMU_PER_BUS qemu: introduce QEMU_CAPS_ARM_SMMUV3_ACCEL qemu: Add support for HW-accelerated nested SMMUv3 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 | 12 ++ src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 15 ++ src/qemu/qemu_validate.c | 20 +++ .../caps_10.0.0_aarch64.replies | 79 ++++++---- .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.2.0_aarch64.replies | 89 +++++++---- .../caps_10.2.0_aarch64.xml | 2 + .../caps_11.0.0_aarch64.replies | 132 ++++++++++++---- .../caps_11.0.0_aarch64.xml | 3 + .../caps_11.1.0_aarch64.replies | 143 ++++++++++++++---- .../caps_11.1.0_aarch64.xml | 3 + .../caps_8.2.0_aarch64.replies | 79 ++++++---- .../caps_8.2.0_aarch64.xml | 1 + .../caps_8.2.0_armv7l.replies | 79 ++++++---- .../caps_8.2.0_armv7l.xml | 1 + .../caps_9.2.0_aarch64+hvf.replies | 75 ++++++--- .../caps_9.2.0_aarch64+hvf.xml | 1 + ...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 + 30 files changed, 1038 insertions(+), 188 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 12

[PATCH] bhyve: lock domain object while handling monitor events
by Roman Bogorodskiy 06 Aug '26

06 Aug '26

virBhyveProcessStop() calls virBhyveDomainObjStopWorker(), which expects the domain object to be locked. It temporarily releases the lock while stopping the event thread and acquires it again before returning. bhyveMonitorIO() called the process stop and restart paths without holding the domain lock. As a result, the lock acquired by virBhyveDomainObjStopWorker() was never released, causing subsequent domain API calls to hang after the guest exited. Lock the domain object while processing the bhyve process exit event and release it after the stop or restart operation completes. Fixes: 0041788857dafa46e047c09c90039209a642cb85 ("bhyve: clean up event thread") Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- src/bhyve/bhyve_monitor.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/bhyve/bhyve_monitor.c b/src/bhyve/bhyve_monitor.c index a24696cad5..a7d7588ee5 100644 --- a/src/bhyve/bhyve_monitor.c +++ b/src/bhyve/bhyve_monitor.c @@ -140,11 +140,13 @@ bhyveMonitorIO(int watch, int kq, int events G_GNUC_UNUSED, void *opaque) } if (kev.filter == EVFILT_PROC && (kev.fflags & NOTE_EXIT) != 0) { + virObjectLock(vm); + if ((pid_t)kev.ident != vm->pid) { virReportError(VIR_ERR_INTERNAL_ERROR, _("event from unexpected proc %1$ju!=%2$ju"), (uintmax_t)vm->pid, (uintmax_t)kev.ident); - return; + goto cleanup; } name = vm->def->name; @@ -169,6 +171,9 @@ bhyveMonitorIO(int watch, int kq, int events G_GNUC_UNUSED, void *opaque) virBhyveProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_UNKNOWN, false); } } + + cleanup: + virObjectUnlock(vm); } } -- 2.52.0

2 4

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

06 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] Commit 9899c91515 introduced the potential for a NULL pointer dereference crash when the 'ctl' parameter to vshPrintStderr() is NULL. Below is an example backtrace of the crash when attempting to detach a non-existent disk with 'virsh detach-disk test vdz'
by Jim Fehlig 04 Aug '26

04 Aug '26

From: Jim Fehlig <jfehlig(a)suse.com> #0 vshPrintStderr (ctl=0x0, level=4, format=<optimized out>, ap=<optimized out>) at ../tools/vsh.c:2148 #1 0x00005555555e6b2c in vshError (ctl=ctl@entry=0x0, format=<optimized out>) at ../tools/vsh.c:2170 #2 0x00005555555afec7 in virshFindDisk (doc=doc@entry=0x555555696ee0 "<domain type='kvm' id='1'>\n <name>test</name>\n <uuid>9b27a21e-dfa2-4c1e-9d11-2de275aefb03</uuid>\n <metadata>\n <libosinfo:libosinfo xmlns:libosinfo=\"http://libosinfo.org/xmlns/libvirt/domain/1."..., path=0x555555651240 "vdz", type=type@entry=0) at ../tools/virsh-domain.c:13055 #3 0x00005555555b0151 in cmdDetachDisk (ctl=0x7fffffffdac0, cmd=0x5555556914c0) at ../tools/virsh-domain.c:13231 #4 0x00005555555e6ddb in vshCommandRun (ctl=ctl@entry=0x7fffffffdac0, cmd=0x5555556914c0) at ../tools/vsh.c:1383 #5 0x000055555559347a in main (argc=<optimized out>, argv=0x7fffffffdeb8) at ../tools/virsh.c:908 Ensure 'ctl' is valid before dereferencing it. Fixes: 9899c91515d79595d19800ccc895df18eb7bb3f7 Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- tools/vsh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/vsh.c b/tools/vsh.c index ccf2f21d64..667cc1a0d2 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -2145,7 +2145,7 @@ vshPrintStderr(vshControl *ctl, if (ctl) vshOutputLogFile(ctl, level, str); - if (ctl->stderr_closed) + if (ctl && ctl->stderr_closed) return; /* Most output is to stdout, but if someone ran virsh 2>&1, then -- 2.51.0

2 3

[PATCH 0/2] conf: Fix schema for capabilities XML
by Peter Krempa 04 Aug '26

04 Aug '26

Peter Krempa (2): conf: schemas: Allow '.' in schema for CPU flag name tests: capabilityschemadata: Add a real test example src/conf/schemas/cputypes.rng | 2 +- .../caps-qemu-real-full.xml | 1033 +++++++++++++++++ 2 files changed, 1034 insertions(+), 1 deletion(-) create mode 100644 tests/capabilityschemadata/caps-qemu-real-full.xml -- 2.55.0

2 3

[PATCH] spec: Fix typo in libvirt-daemon Obsoletes macro expansion
by Jim Fehlig 04 Aug '26

04 Aug '26

From: Jim Fehlig <jfehlig(a)suse.com> Fixes: 07b220964f968284533e589a2ac28cc465fd26ae Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 72fc08f9e7..2411fd94c4 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -309,7 +309,7 @@ Source: https://download.libvirt.org/%{?mainturl}libvirt-%{version}.tar.xz %if %{with_libvirtd} Requires: libvirt-daemon = %{version}-%{release} %else -Obsoletes: libvirt-daemon < %(version)-%(release) +Obsoletes: libvirt-daemon < %{version}-%{release} %endif Requires: libvirt-daemon-config-network = %{version}-%{release} Requires: libvirt-daemon-config-nwfilter = %{version}-%{release} -- 2.51.0

2 1

[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