August 2025 - Devel - libvirt List Archives

[PATCH 00/13] CH: Add disk hotplug support to Cloud Hypervisor domains
by Stefan Kober 04 Sep '25

04 Sep '25

This patchset adds the necessary functionality to support disk hotplugging in the CH driver. Some alias handling that can be extended to other device types is added, in order to allow detaching the devices via the Cloud Hypervisor API. Stefan Kober (13): ch: add DomainAttachDevice skeletons ch: add DomainDetachDevice skeletons ch: add ch_hotplug.{h,c} files to CH build ch: call into ch_hotplug implementation ch: pass disk alias to CHV ch: add ch_alias.{c,h} for device alias handling ch: add virCHMonitorPut function ch: use MonitorPut in MonitorPutNoContent ch: add disk attach functionality ch: assign aliases in ProcessPrepareDomain ch: Add virCHMonitorRemoveDevice function ch: implement disk device hot removal NEWS: announce disk hotplug support for ch NEWS.rst | 5 + po/POTFILES | 1 + src/ch/ch_alias.c | 59 ++++++++ src/ch/ch_alias.h | 27 ++++ src/ch/ch_driver.c | 86 ++++++++++++ src/ch/ch_hotplug.c | 333 ++++++++++++++++++++++++++++++++++++++++++++ src/ch/ch_hotplug.h | 33 +++++ src/ch/ch_monitor.c | 81 +++++++++-- src/ch/ch_monitor.h | 7 + src/ch/ch_process.c | 4 + src/ch/meson.build | 4 + 11 files changed, 630 insertions(+), 10 deletions(-) create mode 100644 src/ch/ch_alias.c create mode 100644 src/ch/ch_alias.h create mode 100644 src/ch/ch_hotplug.c create mode 100644 src/ch/ch_hotplug.h -- 2.50.1

4 20

[PATCHv2] passt: Define backend hostname and fqdn
by Enrique Llorente 03 Sep '25

03 Sep '25

This commit introduces a feature enhancement for configuring hostnames in virtual machines (VMs) using DHCP. It adds new options to the "passt" tool to set the hostname and fully qualified domain name (FQDN) for VMs. These map to DHCP option 12 for the hostname and options 81 (IPv4) and 39 (IPv6) for the FQDN. The update enables passt to dynamically assign hostnames to DHCP-aware VMs. To achieve this, the commit adds two fields to the passt domain XML backend. These fields allow passt to configure the hostname and FQDN for the virtual machine, ensuring smooth integration with the DHCP protocol. This improvement is particularly valuable in environments where VMs need dynamic hostname configuration, enhancing flexibility and automation in virtualized network setups. libvirt: Integrate passt --hostname --fqdn options Resolves: https://issues.redhat.com/browse/RHEL-79806 Signed-off-by: Enrique Llorente <ellorent(a)redhat.com> --- Compared to v1 this fix the mapping between backend fqdn and hostname docs/formatdomain.rst | 8 +++++--- src/conf/domain_conf.c | 10 +++++++++- src/conf/domain_conf.h | 2 ++ src/conf/schemas/domaincommon.rng | 6 ++++++ src/qemu/qemu_passt.c | 6 ++++++ tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml | 2 +- tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml | 2 +- tests/qemuxmlconfdata/net-user-passt.xml | 2 +- .../net-vhostuser-passt.x86_64-latest.xml | 2 +- tests/qemuxmlconfdata/net-vhostuser-passt.xml | 2 +- 10 files changed, 33 insertions(+), 9 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..9c80aa9270 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -5372,10 +5372,12 @@ came from the host's IP. There are a few other options that are configurable only for the passt backend. For example, the ``<backend>`` attribute ``logFile`` can be used to tell the passt process for this interface where to write its -message log, and the ``<source>`` attribute ``dev`` can tell it a +message log, the ``<source>`` attribute ``dev`` can tell it a particular host interface to use when deriving the routes given to the -guest for forwarding traffic upstream. Due to the design decisions of -passt, when using SELinux on the host, it is recommended that the log +guest for forwarding traffic upstream and the ``hostname`` and ``fqdn`` +will conigure the DHCP option 12 hostname and DHCP option 81 and DHCPv6 +option 39 fqdn attribute. Due to the design decisions of passt, when using +SELinux on the host, it is recommended that the log file reside in the runtime directory of the user under which the passt process will run, most probably ``/run/user/$UID`` (where ``$UID`` is the UID of that user), e.g. ``/run/user/1000``. Be aware that libvirt diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b3b0bd7329..15143f8fa2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2909,6 +2909,8 @@ virDomainNetDefFree(virDomainNetDef *def) g_free(def->backend.tap); g_free(def->backend.vhost); g_free(def->backend.logFile); + g_free(def->backend.hostname); + g_free(def->backend.fqdn); virDomainNetTeamingInfoFree(def->teaming); g_free(def->virtPortProfile); g_free(def->script); @@ -9757,6 +9759,8 @@ virDomainNetBackendParseXML(xmlNodePtr node, } def->backend.logFile = virXMLPropString(node, "logFile"); + def->backend.hostname = virXMLPropString(node, "hostname"); + def->backend.fqdn = virXMLPropString(node, "fqdn"); if (tap) def->backend.tap = virFileSanitizePath(tap); @@ -20757,7 +20761,9 @@ virDomainNetBackendIsEqual(virDomainNetBackend *src, if (src->type != dst->type || STRNEQ_NULLABLE(src->tap, dst->tap) || STRNEQ_NULLABLE(src->vhost, dst->vhost) || - STRNEQ_NULLABLE(src->logFile, dst->logFile)) { + STRNEQ_NULLABLE(src->logFile, dst->logFile) || + STRNEQ_NULLABLE(src->hostname, dst->hostname) || + STRNEQ_NULLABLE(src->fqdn, dst->fqdn)) { return false; } return true; @@ -24838,6 +24844,8 @@ virDomainNetBackendFormat(virBuffer *buf, virBufferEscapeString(&attrBuf, " tap='%s'", backend->tap); virBufferEscapeString(&attrBuf, " vhost='%s'", backend->vhost); virBufferEscapeString(&attrBuf, " logFile='%s'", backend->logFile); + virBufferEscapeString(&attrBuf, " hostname='%s'", backend->hostname); + virBufferEscapeString(&attrBuf, " fqdn='%s'", backend->fqdn); virXMLFormatElement(buf, "backend", &attrBuf, NULL); } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 58b97a2b54..79fd2f1f63 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1067,6 +1067,8 @@ struct _virDomainNetBackend { char *vhost; /* The following are currently only valid/used when backend type='passt' */ char *logFile; /* path to logfile used by passt process */ + char *hostname; /* hostname of the passt process */ + char *fqdn; /* fully qualified domain name of the passt process */ }; struct _virDomainNetPortForwardRange { diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng index 5597d5a66b..f64199ca18 100644 --- a/src/conf/schemas/domaincommon.rng +++ b/src/conf/schemas/domaincommon.rng @@ -3913,6 +3913,12 @@ <ref name="absFilePath"/> </attribute> </optional> + <optional> + <attribute name="hostname"/> + </optional> + <optional> + <attribute name="fqdn"/> + </optional> </element> </optional> <optional> diff --git a/src/qemu/qemu_passt.c b/src/qemu/qemu_passt.c index fcc34de384..81e5c51f6c 100644 --- a/src/qemu/qemu_passt.c +++ b/src/qemu/qemu_passt.c @@ -229,6 +229,12 @@ qemuPasstStart(virDomainObj *vm, if (net->backend.logFile) virCommandAddArgList(cmd, "--log-file", net->backend.logFile, NULL); + if (net->backend.hostname) + virCommandAddArgList(cmd, "--hostname", net->backend.hostname, NULL); + + if (net->backend.fqdn) + virCommandAddArgList(cmd, "--fqdn", net->backend.fqdn, NULL); + /* Add IP address info */ for (i = 0; i < net->guestIP.nips; i++) { const virNetDevIPAddr *ip = net->guestIP.ips[i]; diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml index cfe07cc627..77da297936 100644 --- a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml +++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml index d7e0ef5f90..917a9edaa0 100644 --- a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-user-passt.xml b/tests/qemuxmlconfdata/net-user-passt.xml index 20c9f50542..80d15de2ed 100644 --- a/tests/qemuxmlconfdata/net-user-passt.xml +++ b/tests/qemuxmlconfdata/net-user-passt.xml @@ -47,7 +47,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml index 529aff11f8..5802754c4b 100644 --- a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml @@ -53,7 +53,7 @@ <range start='443' to='344'/> </portForward> <model type='virtio'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <interface type='vhostuser'> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.xml index 71b845329b..0a37511a0f 100644 --- a/tests/qemuxmlconfdata/net-vhostuser-passt.xml +++ b/tests/qemuxmlconfdata/net-vhostuser-passt.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='virtio'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <interface type='vhostuser'> -- 2.49.0

6 12

[PATCH v3 1/1] docs : add doc on cpu model and features
by Hector Cao 02 Sep '25

02 Sep '25

Add documentation on the way libvirt displays the Host CPU model and capabilities (features). There is an implicit expectation from users to get the CPU model name matching the CPU model they are running on, however, this does not happen most of the time. As a consequence, having a documentation is useful both for users to align their expectation and for us to point to a place where the situation is clearly explained. Signed-off-by: Hector Cao <hector.cao(a)canonical.com> --- docs/formatcaps.rst | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst index 7e525487e7..3cf83b7c6a 100644 --- a/docs/formatcaps.rst +++ b/docs/formatcaps.rst @@ -97,6 +97,50 @@ The ``<host/>`` element consists of the following child elements: parse this element. In contrast with the former elements, this is repeated for each security model the libvirt daemon currently supports. +Host CPU model and features +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As described previously in this section, libvirt exposes to +users the list of Host CPU features. Libvirt has a special way to +expose this list: Instead of providing the full (and thereby often +very long) set of features, libvirt specifies a CPU model as +baseline and additional features on top of it (as can be seen in +`Examples`_ where the baseline is ``Skylake-Client-noTSX-IBRS``). + +The ideal case would be that the baseline CPU model definition matches +exactly the CPU present in the system, and no additional feature is +needed to express the capabilities of the CPU. For example, if you are +running on a Server CPU you bought as ``Icelake`` type, the returned +CPU model name could be ``Icelake-Server``. However, this ideal +situation rarely happens, for two main reasons: + +- Manufacturers do not ship a single type of CPU under a given name, + there are various different SKUs with different features under the + same name. Yet it is not practical to have a database listing all of + those variants. + +- Some features might be in the hardware but unavailable for various + reasons (BIOS and kernel configuration, disabled for security, + ...). One typical example where this situation happens is related to + the `TSX mitigation <https://docs.kernel.org/arch/x86/tsx_async_abort.html>`__. + As a mitigation to the TAA side channel attack, the Linux kernel disables + by default TSX and its 2 features, ``rtm`` and ``hle``. Since many Linux + distributions keep this safer default behavior, these 2 features appear + as missing. + +Because for backward compatibility reasons, host capabilities cannot +list features that would need to be removed from the baseline model to +describe the host CPU, libvirt has to often use a rather old CPU +model, for example, ``Broadwell`` rather than ``Icelake``. Therefore, +users *shouldnot* expect the reported CPU model name to have any +implications other than that of a named baseline to build the complete +available feature set of the Host CPU. + +`Domain capabilities <formatdomaincaps.html#cpu-configuration>`_ do +not have such limitation, and the ``host-model`` CPU definition would +show the correct CPU model in almost all cases. + + Guest capabilities ~~~~~~~~~~~~~~~~~~ -- 2.45.2

2 1

[PATCH 0/3] hw/sd/sdcard: Deprecate support for spec v1.10
by Philippe Mathieu-Daudé 02 Sep '25

02 Sep '25

Deprecate SD spec v1.10, use v3.01 as new default. Philippe Mathieu-Daudé (3): hw/sd/sdcard: Deprecate support for spec v1.10 hw/sd/sdcard: Use spec v3.01 by default hw/sd/sdcard: Remove support for spec v1.10 docs/about/removed-features.rst | 5 +++++ include/hw/sd/sd.h | 1 - hw/sd/sd.c | 14 +++----------- 3 files changed, 8 insertions(+), 12 deletions(-) -- 2.41.0

2 10

[PATCH] qapi: net/tap: deprecate vhostforce option
by Vladimir Sementsov-Ogievskiy 01 Sep '25

01 Sep '25

This option simply duplicates the @vhost option since long ago (10 years!) commit 1e7398a140f7a6 ("vhost: enable vhost without without MSI-X"). Let's finally deprecate it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)yandex-team.ru> --- docs/about/deprecated.rst | 7 +++++++ qapi/net.json | 6 +++++- 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index d50645a071..d14cb37480 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -516,6 +516,13 @@ Stream ``reconnect`` (since 9.2) The ``reconnect`` option only allows specifying second granularity timeouts, which is not enough for all types of use cases, use ``reconnect-ms`` instead. +TAP ``vhostforce`` (since 10.2) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``vhostforce`` option just duplicates the main ``vhost`` option. +Use ``vhost`` alone. + + VFIO device options ''''''''''''''''''' diff --git a/qapi/net.json b/qapi/net.json index 78bcc9871e..d1216bb60a 100644 --- a/qapi/net.json +++ b/qapi/net.json @@ -353,6 +353,10 @@ # @poll-us: maximum number of microseconds that could be spent on busy # polling for tap (since 2.7) # +# Features: +# +# @deprecated: Member @vhostforce is deprecated. Simply use @vhost. +# # Since: 1.2 ## { 'struct': 'NetdevTapOptions', @@ -369,7 +373,7 @@ '*vhost': 'bool', '*vhostfd': 'str', '*vhostfds': 'str', - '*vhostforce': 'bool', + '*vhostforce': { 'type': 'bool', 'features': [ 'deprecated' ] }, '*queues': 'uint32', '*poll-us': 'uint32'} } -- 2.48.1

2 4

[PATCH 0/8] qemu-replies-tool: Improvements for .replies comparison
by Peter Krempa 01 Sep '25

01 Sep '25

Add few more stable dumps to help comparing two .replies files (especially useful when updating to new git versions of qemu) Peter Krempa (8): scripts: qemu-replies-tool: Convert the QMP conversation to list of dicts scripts: qemu-replies-tool: Drop specific invocation of marginally useful dump modes scripts: qemu-replies-tool: Dump machine types in --dump-all scripts: qemu-replies-tool: List also data from 'qom-list-properties' scripts: qemu-replies-tool: Prefix output with filename when dumping data for multiple files scripts: qemu-replies-tool: Dump data from query-version/query-target/query-kvm scripts: qemu-replies-tool: Add stable dump of 'query-command-line-options' scripts: qemu-replies-tool: Add option to dump JSON commands that weren't processed by --dump-all scripts/qemu-replies-tool.py | 271 ++++++++++++++++++++++++++--------- 1 file changed, 207 insertions(+), 64 deletions(-) -- 2.51.0

2 9

[PATCH 0/2] hw/mips: Remove mipssim machine and mipsnet device
by Philippe Mathieu-Daudé 01 Sep '25

01 Sep '25

mipssim machine (single user of mipsnet device) is deprecated since v10.0; remove for 10.2. Philippe Mathieu-Daudé (2): hw/mips: Remove mipssim machine hw/net: Remove mipsnet device model MAINTAINERS | 6 - docs/about/deprecated.rst | 12 - docs/about/removed-features.rst | 5 + docs/system/target-mips.rst | 11 - configs/devices/mips-softmmu/common.mak | 1 - hw/mips/mipssim.c | 249 -------------------- hw/net/mipsnet.c | 297 ------------------------ hw/mips/Kconfig | 7 - hw/mips/meson.build | 1 - hw/net/Kconfig | 3 - hw/net/meson.build | 1 - hw/net/trace-events | 7 - 12 files changed, 5 insertions(+), 595 deletions(-) delete mode 100644 hw/mips/mipssim.c delete mode 100644 hw/net/mipsnet.c -- 2.51.0

4 6

[PATCH v2 0/2] Introduce virDomainBlockRebase2 API
by Nikolai Barybin 29 Aug '25

29 Aug '25

During first series discussion we agreed on having API that do both - block pull and block copy was a mistake. Thus, I present 'block-stream-only' API. Changes since last revision: - Dropped block-copy functionality - Enabled bandwidth units as params, not as a flag - Improved documentation P.S. Not sure we need virsh support at this stage, because current params can be covered with 'virsh blockpull'. But if you propose more params or we want account for future changes, I can add virsh support. Nikolai Barybin (2): api: remote: introduce virDomainBlockRebase2 API qemu: implement driver support for domainBlockRebase2 API include/libvirt/libvirt-domain.h | 43 +++++++++++++++++++++ src/driver-hypervisor.h | 8 ++++ src/libvirt-domain.c | 65 ++++++++++++++++++++++++++++++++ src/libvirt_public.syms | 5 +++ src/qemu/qemu_driver.c | 48 +++++++++++++++++++++++ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 17 ++++++++- src/remote_protocol-structs | 10 +++++ 8 files changed, 196 insertions(+), 1 deletion(-) -- 2.43.5

2 3

[RFC PATCH 0/5] cover letter: qemu: Implement support for iommufd and multiple vSMMUs
by Nathan Chen 28 Aug '25

28 Aug '25

Hi, This is a follow up to the second RFC patchset [0] for supporting multiple vSMMU instances and using iommufd to propagate DMA mappings to kernel for VM-assigned host devices in a qemu VM. This patchset implements support for specifying multiple <iommu> devices within the VM definition when smmuv3Dev IOMMU model is specified, and is tested with Shameer's latest qemu RFC for HW-accelerated vSMMU devices [1] Moreover, it adds a new 'iommufdId' attribute for hostdev devices to be associated with the iommufd object. For instance, specifying the iommufd object and associated hostdev in a VM definition with multiple IOMMUs, 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> <iommufdId>iommufd0</iommufdId> <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> <iommufdId>iommufd0</iommufdId> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3Dev' parentIdx='1' accel='on'/> <iommu model='smmuv3Dev' parentIdx='2' accel='on'/> </devices> This would get translated to a qemu command line with the arguments below. Note that libvirt will open the /dev/iommu and VFIO cdev, passing the associated fd number to qemu: -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"}' \ -object '{"qom-type":"iommufd","id":"iommufd0","fd":"24"}' \ -device '{"driver":"arm-smmuv3-accel","primary-bus":"pci.1","id":"smmuv3.0","accel":true}' \ -device '{"driver":"arm-smmuv3-accel","primary-bus":"pci.2","id":"smmuv3.1","accel":true}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","fd":"22","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","fd":"25","bus":"pci.22","addr":"0x0"}' \ Summary of changes: - Separated out commits for smmuv3Dev iommu model support and supporting multiple IOMMU definitions - Made iommufd only a hostdev attribute - Revised smmuv3Dev iommu model definition to reference the controller index instead of assigning it a BDF - Open iommufd FDs from libvirt backend without exposing FDs to XML users - Fixed iommufd path permissions - Matched qemu usage of Shameer's latest RFCv3 This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3Dev-iommufd-08-12-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/EASB… [1] https://lore.kernel.org/qemu-devel/20250714155941.22176-1-shameerali.koloth… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (5): qemu: add IOMMU model smmuv3Dev conf: Support multiple smmuv3Dev IOMMU devices qemu: Implement support for associating iommufd to hostdev qemu: open iommufd FDs from libvirt backend qemu: Update Cgroup, namespace, and seclabel for qemu to access iommufd paths docs/formatdomain.rst | 22 ++- src/conf/domain_conf.c | 208 ++++++++++++++++++++++-- src/conf/domain_conf.h | 13 +- src/conf/domain_validate.c | 58 +++++-- src/conf/schemas/domaincommon.rng | 24 ++- src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 15 +- src/qemu/qemu_cgroup.c | 61 +++++++ src/qemu/qemu_cgroup.h | 1 + src/qemu/qemu_command.c | 261 ++++++++++++++++++++++-------- src/qemu/qemu_command.h | 3 +- src/qemu/qemu_domain.c | 8 + src/qemu/qemu_domain.h | 7 + src/qemu/qemu_domain_address.c | 33 ++-- src/qemu/qemu_driver.c | 8 +- src/qemu/qemu_hotplug.c | 2 +- src/qemu/qemu_namespace.c | 44 +++++ src/qemu/qemu_postparse.c | 11 +- src/qemu/qemu_process.c | 232 ++++++++++++++++++++++++++ src/qemu/qemu_validate.c | 18 ++- src/security/security_apparmor.c | 11 ++ src/security/security_dac.c | 23 +++ src/security/security_selinux.c | 24 +++ src/util/virpci.c | 68 ++++++++ src/util/virpci.h | 1 + 25 files changed, 1020 insertions(+), 138 deletions(-) -- 2.43.0

2 11

[PATCH v2 0/6] Enable mshv support for Qemu domains
by Praveen K Paladugu 28 Aug '25

28 Aug '25

"[PATCH v3 00/26] Implementing a MSHV (Microsoft Hypervisor) accelerator" patchset in qemu-devel mailing list introduces MSHV support within Qemu. With above patchset, Qemu guests can be started with `-accel mshv` option to use Microsoft Hypervisor (/dev/mshv) as the hypervisor. Retaining Libvirt's naming convention, this translates to `hyperv` domains. Below is an excerpt of the xml to use with this patchset: ``` <domain type='hyperv'> <name>qemu_msh_testv</name> <cpu mode='host-model'/> <os> <type machine='q35'>hvm</type> </os> ... ``` This patch set introduces the necessary changes within libvirt to support Qemu guest with hyperv (mshv) hypervisor. Changes in v2: - Addressed review comments on v1. - Added a test to verify mshv capabilities. Praveen K Paladugu (6): qemu: introduce mshv capabilities qemu: use mshv accel for hyperv domains qemu: add /dev/mshv to default cgroup acl qemu: probe mshv capabilities conf: update capability schema tests: Introduce tests for mshv capabilities src/conf/schemas/capability.rng | 1 + src/qemu/qemu.conf.in | 2 +- src/qemu/qemu_capabilities.c | 61 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_command.c | 4 +- src/qemu/qemu_monitor.c | 12 + src/qemu/qemu_monitor.h | 12 +- src/qemu/qemu_monitor_json.c | 32 +- src/qemu/qemu_monitor_json.h | 13 +- src/qemu/test_libvirtd_qemu.aug.in | 3 +- .../caps_11.3.0_x86_64+mshv.replies | 46912 ++++++++++++++++ .../caps_11.3.0_x86_64+mshv.xml | 4996 ++ .../qemucaps2xmloutdata/caps.x86_64+mshv.xml | 29 + 14 files changed, 52060 insertions(+), 20 deletions(-) create mode 100644 tests/qemucapabilitiesdata/caps_11.3.0_x86_64+mshv.replies create mode 100644 tests/qemucapabilitiesdata/caps_11.3.0_x86_64+mshv.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+mshv.xml -- 2.50.1

2 12