- Devel - libvirt List Archives

[PATCH v2 00/29] Introduce hyperv host-model mode
by Michal Privoznik 15 Oct '25

15 Oct '25

v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/DFOD… diff to v1: - Validate dependencies across hv-* enlightenment (per QEMU docs), - Drop introduction of hv-time, since it's already present (as a timer), I've kept mode='host-model' in domain XML and <defaults/> in domcaps XML, since no one objected, yet. Michal Prívozník (29): docs: Fix QEMU version wrt hypervclock src: Drop needless typecast to virDomainTimerNameType conf: Introduce virDomainDefHasTimer() qemuxmlconfdata: Adjust hv-stimer related tests qemu_validate: Reflect dependencies of hv-synic qemu_validate: Reflect dependencies of hv-stimer qemu_validate: Reflect dependencies of hv-tlbflush qemu_validate: Reflect dependencies of hv-ipi qemu_validate: Reflect dependencies of hv-evmcs qemu_validate: Reflect dependencies of hv-tlbflush-direct NEWS: Document Hyper-V enlightenment validation virxml: Introduce virXPathTristateSwitch() virxml: Introduce virXPathTristateBool() qemu: Use virXPathTristateBool() domain_conf: Move format of hyperv features into a function domain_conf: Use virXMLFormatElement() to format hyperv features qemu_caps: Prefer VIR_DOMAIN_CAPS_ENUM_IS_SET() qemu_command: Move hyperv cmd line generation into a function qemu_command: Prefer virBufferAddLit() in qemuBuildCpuHypervCommandLine() libxl: Simplify setting HyperV features conf: More hyperv related members into a single struct docs: Drop remark on now unsupported version of QEMU conf: Report default hyperv values in domain capabilities qemu_capabilities: Format and parse new hyperv domcaps members qemu_capabilities: Fetch new hyperv domcaps qemu_caps: Introduce virQEMUCapsGetHypervCapabilities() conf: Introduce hyperv host-model mode qemu_process: Populate hyperv features for host-model NEWS: Document new host-model hyperv mode NEWS.rst | 11 + docs/formatdomain.rst | 8 +- docs/formatdomaincaps.rst | 9 +- src/conf/domain_capabilities.c | 61 ++++- src/conf/domain_capabilities.h | 11 + src/conf/domain_conf.c | 235 ++++++++++-------- src/conf/domain_conf.h | 20 +- src/conf/schemas/domaincaps.rng | 29 +++ src/conf/schemas/domaincommon.rng | 3 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 5 + src/libxl/libxl_conf.c | 70 +++--- src/libxl/xen_common.c | 2 +- src/lxc/lxc_cgroup.c | 2 +- src/lxc/lxc_controller.c | 2 +- src/qemu/qemu_capabilities.c | 107 +++++++- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 162 ++++++------ src/qemu/qemu_domain.c | 16 +- src/qemu/qemu_process.c | 80 +++++- src/qemu/qemu_validate.c | 74 +++++- src/util/virxml.c | 68 +++++ src/util/virxml.h | 10 + .../qemu_10.0.0-q35.x86_64+amdsev.xml | 7 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 7 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 7 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 7 + .../qemu_10.0.0.x86_64+amdsev.xml | 7 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 7 + .../qemu_10.1.0-q35.x86_64+inteltdx.xml | 7 + .../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 7 + .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 7 + .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 7 + .../qemu_10.1.0.x86_64+inteltdx.xml | 7 + tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 7 + .../domaincapsdata/qemu_10.2.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_10.2.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_10.2.0.x86_64.xml | 7 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 7 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 7 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 7 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 7 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 7 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 7 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 7 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 7 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 7 + .../qemu_9.2.0.x86_64+amdsev.xml | 7 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 7 + .../caps_10.0.0_x86_64+amdsev.xml | 5 + .../caps_10.0.0_x86_64.xml | 5 + .../caps_10.1.0_x86_64+inteltdx.xml | 5 + .../caps_10.1.0_x86_64.xml | 5 + .../caps_10.2.0_x86_64.xml | 5 + .../caps_8.0.0_x86_64.xml | 5 + .../caps_8.1.0_x86_64.xml | 5 + .../caps_8.2.0_x86_64.xml | 5 + .../caps_9.0.0_x86_64.xml | 5 + .../caps_9.1.0_x86_64.xml | 5 + .../caps_9.2.0_x86_64+amdsev.xml | 5 + .../caps_9.2.0_x86_64.xml | 5 + .../hyperv-host-model.x86_64-latest.args | 32 +++ .../hyperv-host-model.x86_64-latest.xml | 33 +++ tests/qemuxmlconfdata/hyperv-host-model.xml | 27 ++ .../hyperv-passthrough.x86_64-latest.xml | 3 +- .../hyperv-stimer-direct.x86_64-latest.args | 2 +- .../hyperv-stimer-direct.x86_64-latest.xml | 4 +- .../qemuxmlconfdata/hyperv-stimer-direct.xml | 4 +- .../qemuxmlconfdata/hyperv.x86_64-latest.args | 2 +- .../qemuxmlconfdata/hyperv.x86_64-latest.xml | 4 +- tests/qemuxmlconfdata/hyperv.xml | 4 +- tests/qemuxmlconftest.c | 1 + 82 files changed, 1151 insertions(+), 267 deletions(-) create mode 100644 tests/qemuxmlconfdata/hyperv-host-model.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hyperv-host-model.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hyperv-host-model.xml -- 2.49.1

4 38

[PATCH 0/2] allow migrations with the ext transport
by Sergey Dyasli 14 Oct '25

14 Oct '25

Hello, I have a use case for live-migration where the socket of the destination libvirtd is proxied by an mTLS WebSocket proxy. Since there is no WebSocket support in Libvirt, I've decided to use the existing ext transport and point it to a proxy binary on the source host of live-migration. While doing that, I've discovered a couple of roadblocks: 1. There is no way of passing cmdline arguments to the ext program 2. Live-migrations using ext transport fail localhost checks This short series addresses those limitations. Sergey Dyasli (2): remote: allow passing cmd arguments to REMOTE_DRIVER_TRANSPORT_EXT remote: allow migrations with the ext transport src/libvirt-domain.c | 8 +++++--- src/remote/remote_driver.c | 30 ++++++++++++++++++++++++++---- src/util/viruri.c | 32 ++++++++++++++++++++++++++++++++ src/util/viruri.h | 2 ++ 4 files changed, 65 insertions(+), 7 deletions(-) -- 2.39.3

2 5

[PATCH 0/7] qemu: Node reactivation and 'manual' disk snapshot enhancements
by Peter Krempa 14 Oct '25

14 Oct '25

Peter Krempa (7): qemu: monitor: Track inactive state of block nodes in 'qemuBlockNamedNodeData' qemu: block: Introduce helper function to ensure that block nodes are active qemu: Re-activate block nodes before storage operations qemu: migration: Don't reactivate block nodes after migration failure any more qemu: snapshot: Deactivate block nodes on manually snapshotted disks qemu: snapshot: Allow snapshot consisting only of 'manual'-y handled disks docs: snapshot: Add a note that blockjobs ought to be avoided with 'manual' snapshots docs/formatsnapshot.rst | 7 ++- src/qemu/qemu_backup.c | 3 ++ src/qemu/qemu_block.c | 52 +++++++++++++++++++++ src/qemu/qemu_block.h | 4 ++ src/qemu/qemu_checkpoint.c | 12 +++++ src/qemu/qemu_driver.c | 9 ++++ src/qemu/qemu_migration.c | 53 ++------------------- src/qemu/qemu_monitor.h | 4 ++ src/qemu/qemu_monitor_json.c | 5 ++ src/qemu/qemu_snapshot.c | 91 +++++++++++++++++++++++++++++++++++- 10 files changed, 188 insertions(+), 52 deletions(-) -- 2.51.0

2 8

[RFC PATCH v4 0/5] Added virtio-net RSS with eBPF support.
by Andrew Melnychenko 14 Oct '25

14 Oct '25

This series of rfc patches adds support for loading the RSS eBPF program and passing it to the QEMU. Comments and suggestions would be useful. QEMU with vhost may work with RSS through eBPF. To load eBPF, the capabilities required that Libvirt may provide. eBPF program and maps may be unique for particular QEMU and Libvirt retrieves eBPF through qapi. For now, there is only "RSS" eBPF object in QEMU, in the future, there may be another one(g.e. network filters). That's why in Libvirt added logic to load and store any eBPF object that QEMU provides using qapi schema. One of the reasons why this series of patches is in RFC are tests. To this series of patches, the tests were added. For now, the tests are synthetic, the proper "reply" file should be generated with a new "caps" file. Currently, there are changes in caps-9.0.0* and caps-9.1.0 files. There was added support for ebpf_rss_fds feature, and request-ebpf command. So, overall, the tests are required for review, comment, and discussion how we want them to be implemented in the future. For virtio-net RSS, the document has not changed. ``` <interface type="network"> <model type="virtio"/> <driver queues="4" rss="on" rss_hash_report="off"/> <interface type="network"> ``` Simplified routine for RSS: * Libvirt retrieves eBPF "RSS" and load it. * Libvirt passes file descriptors to virtio-net with property "ebpf_rss_fds" ("rss" property should be "on" too). * if fds was provided - QEMU using eBPF RSS implementation. * if fds was not provided - QEMU tries to load eBPF RSS in own context and use it. * if eBPF RSS was not loaded - QEMU uses "in-qemu" RSS(vhost not supported). Changes since RFC v3: * changed tests a bit * refactored and rebased * removed "allowEBPF" from qemu config(now env is used for tests) Changes since RFC v2: * refactored and rebased. * applied changes according to the Qemu. * added basic test. Changes since RFC v1: * changed eBPF format saved in the XML cache. * refactored and checked with syntax test. * refactored patch hunks. Andrew Melnychenko (5): qemu_monitor: Added QEMU's "request-ebpf" support. qemu_capabilities: Added logic for retrieving eBPF objects from QEMU. qemu_interface: Added routine for loading the eBPF objects. qemu_command: Added "ebpf_rss_fds" support for virtio-net. tests: Added tests for eBPF blob loading. libvirt.spec.in | 3 + meson.build | 7 + meson_options.txt | 1 + src/qemu/meson.build | 1 + src/qemu/qemu_capabilities.c | 132 ++++++++++++ src/qemu/qemu_capabilities.h | 5 + src/qemu/qemu_command.c | 60 ++++++ src/qemu/qemu_domain.c | 4 + src/qemu/qemu_domain.h | 3 + src/qemu/qemu_interface.c | 87 ++++++++ src/qemu/qemu_interface.h | 7 + src/qemu/qemu_monitor.c | 9 + src/qemu/qemu_monitor.h | 4 + src/qemu/qemu_monitor_json.c | 27 +++ src/qemu/qemu_monitor_json.h | 4 + .../caps_9.0.0_sparc.replies | 95 +++++---- .../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 3 + .../caps_9.0.0_x86_64.replies | 199 ++++++++++-------- .../caps_9.0.0_x86_64.xml | 4 + .../caps_9.1.0_x86_64.replies | 199 ++++++++++-------- .../caps_9.1.0_x86_64.xml | 4 + tests/qemuxml2argvmock.c | 24 +++ .../net-virtio-rss-bpf.x86_64-latest.args | 37 ++++ .../net-virtio-rss-bpf.x86_64-latest.xml | 46 ++++ tests/qemuxmlconfdata/net-virtio-rss-bpf.xml | 46 ++++ tests/qemuxmlconftest.c | 5 + 26 files changed, 792 insertions(+), 224 deletions(-) create mode 100644 tests/qemuxmlconfdata/net-virtio-rss-bpf.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/net-virtio-rss-bpf.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/net-virtio-rss-bpf.xml -- 2.45.2

3 7

[PATCH 0/8] wireshark: Adapt to wireshark-4.6.0
by Michal Privoznik 14 Oct '25

14 Oct '25

There are only a handful of distros that offer newest wireshark (released just a couple of days ago). Well, there were some changes to the API so we have to adjust. See: https://gitlab.com/libvirt/libvirt/-/issues/82 See: https://bugs.gentoo.org/963985 Michal Prívozník (8): wireshark: Drop needless declaration of proto_register_libvirt() and proto_reg_handoff_libvirt() wireshark: Switch header files to #pragma once wireshark: Move WIRESHARK_VERSION macro definition wireshark: Fix int type of some virNetMessageHeader members wireshark: Don't special case retval of get_program_data() in dissect_libvirt_message() wireshark: Introduce and use vir_val_to_str() wireshark: Don't leak column strings wireshark: Adapt to wireshark-4.6.0 meson.build | 20 +++ tools/wireshark/src/meson.build | 1 + tools/wireshark/src/packet-libvirt.c | 207 ++++++++++++++++++++------- tools/wireshark/src/packet-libvirt.h | 14 ++ tools/wireshark/src/plugin.c | 17 --- tools/wireshark/util/genxdrstub.pl | 23 ++- 6 files changed, 199 insertions(+), 83 deletions(-) -- 2.49.1

3 19

[PATCH v3] libvirt-ci: remove obsolete RISC-V ports setup for Debian 13+
by yangzewei＠loongson.cn 13 Oct '25

13 Oct '25

From: yzewei <yangzewei(a)loongson.cn> This patch combines previous v1 and v2 patches, Please ignore previous patches v1 and v2. - Remove obsolete RISC-V ports setup for Debian 13+ Debian 13 and later officially support riscv64, so the old debian-ports archive keyring and sources.list configuration are no longer necessary. - Add validation to forbid RISC-V cross compilation on Debian < 13 Ensures that cross compiling for riscv64 on unsupported Debian releases fails early with a clear error message. Signed-off-by: yzewei <yangzewei(a)loongson.cn> --- lcitool/formatters.py | 15 --------------- lcitool/projects.py | 2 +- lcitool/util.py | 4 +++- 3 files changed, 4 insertions(+), 17 deletions(-) diff --git a/lcitool/formatters.py b/lcitool/formatters.py index c26cf22a..af171fae 100644 --- a/lcitool/formatters.py +++ b/lcitool/formatters.py @@ -456,21 +456,6 @@ class BuildEnvFormatter(Formatter): "dpkg --add-architecture {cross_arch_deb}", ] ) - if target.cross_arch == "riscv64": - cross_commands.extend( - [ - "{nosync}{packaging_command} install debian-ports-archive-keyring", - "{nosync}echo 'deb http://ftp.ports.debian.org/debian-ports/ sid main' > /etc/apt/sources.list.d/ports.list", - "{nosync}echo 'deb http://ftp.ports.debian.org/debian-ports/ unreleased main' >> /etc/apt/sources.list.d/ports.list", - ] - ) - cross_commands.extend( - [ - "{nosync}{packaging_command} update", - "{nosync}{packaging_command} dist-upgrade -y", - "{nosync}{packaging_command} install --no-install-recommends -y dpkg-dev", - ] - ) if varmap["cross_pkgs"]: cross_commands.extend( [ diff --git a/lcitool/projects.py b/lcitool/projects.py index f1187cb2..0324f21a 100644 --- a/lcitool/projects.py +++ b/lcitool/projects.py @@ -270,7 +270,7 @@ class Project: target_name = f"{target_name}" else: try: - util.validate_cross_platform(target.cross_arch, osname) + util.validate_cross_platform(target.cross_arch, osname, osversion) except ValueError as ex: raise ProjectError(str(ex)) target_name = f"{target_name}-{target.cross_arch}-cross" diff --git a/lcitool/util.py b/lcitool/util.py index 3f5cb870..aedf3882 100644 --- a/lcitool/util.py +++ b/lcitool/util.py @@ -409,10 +409,12 @@ class DataDir: return result -def validate_cross_platform(cross_arch: str, osname: str) -> None: +def validate_cross_platform(cross_arch: str, osname: str, osversion: str) -> None: if osname not in ["Debian", "Fedora"]: raise ValueError(f"Cannot cross compile on {osname}") if osname == "Debian" and cross_arch.startswith("mingw"): raise ValueError(f"Cannot cross compile for {cross_arch} on {osname}") if osname == "Fedora" and not cross_arch.startswith("mingw"): raise ValueError(f"Cannot cross compile for {cross_arch} on {osname}") + if osname == "Debian" and cross_arch == "riscv64" and int(osversion.split('.')[0]) < 13: + raise ValueError(f"Cross compiling for {cross_arch} is not supported on Debian < 13") -- 2.43.0

2 1

[PATCH v2] libvirt-ci: forbid RISC-V cross compile on Debian < 13
by 杨泽伟 11 Oct '25

11 Oct '25

From 3c3ebcea07d20977f30baedcec50a859c1ac04a5 Mon Sep 17 00:00:00 2001 From: yzewei <yangzewei(a)loongson.cn> Date: Sat, 11 Oct 2025 09:39:29 +0800 Subject: [PATCH] This patch updates [PATCH v1] to add validation: RISC-V cross compilation is forbidden on Debian < 13. Signed-off-by: yzewei <yangzewei(a)loongson.cn> --- lcitool/projects.py | 2 +- lcitool/util.py | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/lcitool/projects.py b/lcitool/projects.py index f1187cb2..0324f21a 100644 --- a/lcitool/projects.py +++ b/lcitool/projects.py @@ -270,7 +270,7 @@ class Project: target_name = f"{target_name}" else: try: - util.validate_cross_platform(target.cross_arch, osname) + util.validate_cross_platform(target.cross_arch, osname, osversion) except ValueError as ex: raise ProjectError(str(ex)) target_name = f"{target_name}-{target.cross_arch}-cross" diff --git a/lcitool/util.py b/lcitool/util.py index 3f5cb870..aedf3882 100644 --- a/lcitool/util.py +++ b/lcitool/util.py @@ -409,10 +409,12 @@ class DataDir: return result -def validate_cross_platform(cross_arch: str, osname: str) -> None: +def validate_cross_platform(cross_arch: str, osname: str, osversion: str) -> None: if osname not in ["Debian", "Fedora"]: raise ValueError(f"Cannot cross compile on {osname}") if osname == "Debian" and cross_arch.startswith("mingw"): raise ValueError(f"Cannot cross compile for {cross_arch} on {osname}") if osname == "Fedora" and not cross_arch.startswith("mingw"): raise ValueError(f"Cannot cross compile for {cross_arch} on {osname}") + if osname == "Debian" and cross_arch == "riscv64" and int(osversion.split('.')[0]) < 13: + raise ValueError(f"Cross compiling for {cross_arch} is not supported on Debian < 13") -- 2.43.0 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

1 0

[PATCH v1] lcitool: remove obsolete RISC-V ports setup for Debian 13+
by 杨泽伟 11 Oct '25

11 Oct '25

From 1603e78297c32f241d7a55f510bae3b8ac16f154 Mon Sep 17 00:00:00 2001 From: yzewei <yangzewei(a)loongson.cn> Date: Fri, 10 Oct 2025 18:01:59 +0800 Subject: [PATCH] lcitool: remove obsolete RISC-V ports setup for Debian 13+ Debian 13 and later officially support riscv64, so the old debian-ports archive keyring and sources.list configuration are no longer necessary. This patch removes the legacy code that adds the debian-ports repositories and installs the debian-ports-archive-keyring package. Signed-off-by: yzewei <yangzewei(a)loongson.cn> --- lcitool/formatters.py | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/lcitool/formatters.py b/lcitool/formatters.py index c26cf22a..af171fae 100644 --- a/lcitool/formatters.py +++ b/lcitool/formatters.py @@ -456,21 +456,6 @@ class BuildEnvFormatter(Formatter): "dpkg --add-architecture {cross_arch_deb}", ] ) - if target.cross_arch == "riscv64": - cross_commands.extend( - [ - "{nosync}{packaging_command} install debian-ports-archive-keyring", - "{nosync}echo 'deb http://ftp.ports.debian.org/debian-ports/ sid main' > /etc/apt/sources.list.d/ports.list", - "{nosync}echo 'deb http://ftp.ports.debian.org/debian-ports/ unreleased main' >> /etc/apt/sources.list.d/ports.list", - ] - ) - cross_commands.extend( - [ - "{nosync}{packaging_command} update", - "{nosync}{packaging_command} dist-upgrade -y", - "{nosync}{packaging_command} install --no-install-recommends -y dpkg-dev", - ] - ) if varmap["cross_pkgs"]: cross_commands.extend( [ -- 2.43.0 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.

2 1

[PATCH v2 0/3] qemu: Implement support for multiple SMMUv3s
by Nathan Chen 11 Oct '25

11 Oct '25

Hi, This is a follow up to the first patchset [0] for supporting multiple vSMMU instances. 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 recently accepted qemu series for user-creatable vSMMU devices [1] For instance, specifying the associated emulated device in a VM definition with multiple IOMMUs, configured to be routed to pcie-expander-bus or pcie-root controllers: <devices> <controller type='pci' index='0' model='pcie-root'/> <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-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x0'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </controller> ... <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </rng> <rng model='virtio'> <backend model='random'>/dev/urandom</backend> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </rng> <iommu model='smmuv3Dev'> <driver parentIdx='0'/> </iommu> <iommu model='smmuv3Dev'> <driver parentIdx='1'/> </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":"pcie-root-port","port":0,"chassis":2,"id":"pci.2","bus":"pci.1","addr":"0x0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pcie.0","id":"smmuv3.0"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"smmuv3.1"}' \ ... -object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \ -device '{"driver":"virtio-rng-pci","rng":"objrng0","id":"rng0","bus":"pci.2","addr":"0x0"}' \ -object '{"qom-type":"rng-random","id":"objrng1","filename":"/dev/urandom"}' \ -device '{"driver":"virtio-rng-pci","rng":"objrng1","id":"rng1","bus":"pcie.0","addr":"0x4"}' \ Changes from v1: - Moved parentIdx attribute under <driver> - Revised qemuxmlconfdata test cases to attach emulated devices This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3Dev-no-accel-09-29-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3PYS… [1] https://lore.kernel.org/qemu-devel/20250829082543.7680-1-skolothumtho@nvidi… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (4): qemu: add IOMMU model smmuv3Dev conf: Support multiple smmuv3Dev IOMMU devices tests: qemuxmlconfdata: provide smmuv3Dev sample XML and CLI args docs/formatdomain.rst | 9 +- src/conf/domain_conf.c | 101 +++++++-- src/conf/domain_conf.h | 11 +- src/conf/domain_validate.c | 58 +++-- src/conf/schemas/domaincommon.rng | 10 +- src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 15 +- src/qemu/qemu_command.c | 202 ++++++++++++------ src/qemu/qemu_domain_address.c | 33 +-- src/qemu/qemu_driver.c | 8 +- src/qemu/qemu_postparse.c | 11 +- src/qemu/qemu_validate.c | 18 +- .../iommu-smmuv3Dev.aarch64-latest.args | 41 ++++ .../iommu-smmuv3Dev.aarch64-latest.xml | 62 ++++++ tests/qemuxmlconfdata/iommu-smmuv3Dev.xml | 49 +++++ tests/qemuxmlconftest.c | 1 + 16 files changed, 499 insertions(+), 132 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3Dev.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3Dev.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3Dev.xml -- 2.43.0

4 10

AI coding policy question
by Cole Robinson 10 Oct '25

10 Oct '25

Hi all, I used claude code to generate (unsubmitted) patches, before I realized libvirt had a policy rejecting AI generated submissions. The patches add domaincapabilities sound model output. If you've looked at code in this area, you know it's largely boilerplate. I'd describe the changes as: + Add the generic domain_capabilities plumbing + Add more QEMU_CAPS flags for all sound devices, copying device names already identified in qemu_command.c + Map qemu caps to domcaps in qemu_capabilities.c + Use domcaps for validation in qemu_validate.c + regenerate testsuite output (and those are basically shorthand for the instructions I gave to the LLM). There does not appear to be a single novel line in the whole series. But OK, for legal safety sake libvirt will not accept these patches. That's fair. But in a copyright sense am I tainted by looking at the generated code? If I wanted to write the patches by hand they likely will end up looking identical, down to the character. Creates a weird scenario IMO. What to do? The patches are here, gaze not upon them lest ye too be corrupted: https://gitlab.com/crobinso/libvirt/-/tree/domcaps-sound Thanks, Cole

2 2