May 2025 - Devel - libvirt List Archives

[PATCH] docs: fix indent of hostdev examples
by Daniel P. Berrangé 02 Jun '25

02 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/formatdomain.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..ca4e84983f 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -4600,15 +4600,15 @@ or: ... <devices> <hostdev mode='subsystem' type='mdev' model='vfio-pci'> - <source> - <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/> - </source> + <source> + <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'/> + </source> </hostdev> <hostdev mode='subsystem' type='mdev' model='vfio-ccw'> <source> <address uuid='9063cba3-ecef-47b6-abcf-3fef4fdcad85'/> </source> - <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> + <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/> </hostdev> </devices> ... -- 2.49.0

2 1

[RFC PATCH 0/5] qemu: Implement support for iommufd and multiple vSMMUs
by Nathan Chen 31 May '25

31 May '25

Hi, This is a follow up to the first RFC patchset [0] for supporting multiple vSMMU instances in a qemu VM. This patchset also introduces support for using iommufd to propagate DMA mappings to kernel for assigned devices. 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 'iommufd' member for virDomainIOMMUDef, in order to represent the iommufd object in qemu command line. This patchset also implements new 'iommufdId' and 'iommufdFd' attributes 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 (pcie-expander-bus and pcie-root-port controllers are no longer auto-added/auto-routed like in the first revision of this RFC, as the PCIe topology will be configured by management apps): <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'> <iommufd> <id>iommufd0</id> </iommufd> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </iommu> <iommu model='smmuv3Dev'> <iommufd> <id>iommufd0</id> </iommufd> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </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"}' \ -object '{"qom-type":"iommufd","id":"iommufd0"}' \ -device '{"driver":"arm-smmuv3-accel","bus":"pci.1"}' \ -device '{"driver":"arm-smmuv3-accel","bus":"pci.2"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","bus":"pci.22","addr":"0x0"}' \ If users would like to leverage qemu's iommufd feature to open the VFIO cdev and /dev/iommu via an external management layer, the fd can be specified like so in the VM definition: <devices> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x06' slot='0x12' function='0x2'/> </source> <iommufdId>iommufd0</iommufdId> <iommufdFd>23</iommufdFd> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </hostdev> <iommu model='intel'> <iommufd> <id>iommufd0</id> <fd>22</fd> </iommufd> </iommu> </devices> This would get translated to a qemu command line with the arguments below: -object '{"qom-type":"iommufd","id":"iommufd0","fd":"22"}' \ -device '{"driver":"vfio-pci","host":"0000:06:12.2","id":"hostdev1","iommufd":"iommufd0","fd":"23","bus":"pci.0","addr":"0x3"}' \ Summary of changes: - Introduced support for specifying multiple <iommu> stanzas in the VM XML definition when using smmuv3Dev model. - Automating PCIe topology to populate VM definition with multiple vSMMUs routed to pcie-expander-bus controllers is excluded, in favor of deferring creation of PXBs and routing of VFIO devices to management apps. - Introduced iommufd support. TODO: - I updated the namespace and cgroup configuration to allow access to iommufd paths at /dev/vfio/devices/vfio* and /dev/iommu. However, qemu needs to be launched with user and group set to 'root' in order for these paths to be accessible. A passthrough device represented by /dev/vfio/18 normally has 'root' user and group permissions, but in the mount namespace it's changed to 'libvirt-qemu' and 'kvm'. I wasn't able to discern where this is happening by looking at src/qemu/qemu_namespace.c and src/qemu/qemu_cgroup.c. Would you have any pointers on how to change the iommufd paths' user and group permissions in the libvirt mount namespace? This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3Dev-iommufd-04-15-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/7GDT… [1] https://lore.kernel.org/qemu-devel/20250311141045.66620-1-shameerali.koloth… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (5): conf: Support multiple smmuv3Dev IOMMU devices conf: Add an iommufd member struct to virDomainIOMMUDef qemu: Implement support for associating iommufd to hostdev qemu: Update Cgroup and namespace for qemu to access iommufd paths qemu: Add test case for specifying iommufd docs/formatdomain.rst | 5 +- src/conf/domain_addr.c | 12 +- src/conf/domain_addr.h | 4 +- src/conf/domain_conf.c | 292 ++++++++++++++++-- src/conf/domain_conf.h | 21 +- src/conf/domain_validate.c | 94 +++++- src/conf/schemas/domaincommon.rng | 37 ++- src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 15 +- src/qemu/qemu_cgroup.c | 47 +++ src/qemu/qemu_cgroup.h | 1 + src/qemu/qemu_command.c | 146 ++++++--- src/qemu/qemu_domain_address.c | 33 +- src/qemu/qemu_driver.c | 8 +- src/qemu/qemu_namespace.c | 36 +++ src/qemu/qemu_postparse.c | 11 +- src/qemu/qemu_validate.c | 22 +- ...fio-iommufd-intel-iommu.x86_64-latest.args | 43 +++ ...vfio-iommufd-intel-iommu.x86_64-latest.xml | 80 +++++ .../hostdev-vfio-iommufd-intel-iommu.xml | 80 +++++ tests/qemuxmlconftest.c | 1 + 22 files changed, 878 insertions(+), 114 deletions(-) create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/hostdev-vfio-iommufd-intel-iommu.xml -- 2.43.0

3 19

[RFC PATCH 0/2] Fix forward type=hostdev nets for apparmor
by Tim Small 30 May '25

30 May '25

I'm working on a fix for a bug whereby apparmor permissions aren't granted to allow a PCI SR-IOV virtual function to be used in a kvm guest when the VF is defined via a forward type='hostdev' network (as per the 'hostdev' option documented here: https://libvirt.org/formatnetwork.html#connectivity ). Downstream bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993856 I'm not sure if the attached patches are sufficient. When I compare the apparmor permissions file for a guest with a VF shared via forward type='hostdev' vs. the same guest with a VF shared via a PCI hostdev device, the latter has extra apparmor permissions for files like: "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3_wc" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0_wc" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource3" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/vendor" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/reset" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/device" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/resource0" rw, "/sys/devices/pci0000:00/0000:00:1d.0/0000:03:10.0/config" rw, ... however both guests appear to function in my test environment (Debian 13, 6.12.22-amd64) - i.e. both with and without those entries. So I don't know if those permissions are unneeded, or if they are granted at runtime instead. If those permissions are needed, then I'd appreciate any hints on how to modify virt-aa-helper to discover the PCI address. I appreciate that might not actually be possible because that is dynamically allocated, and so might race - so some other solution might be required. Many Thanks, Tim. Tim Small (2): virt-aa-helper: refactor for readability virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks .../apparmor/usr.lib.libvirt.virt-aa-helper.in | 3 +++ src/security/virt-aa-helper.c | 18 ++++++++++++++---- 2 files changed, 17 insertions(+), 4 deletions(-) -- 2.47.2

2 8

[PATCH v2] NEWS: Mention removal of compile time helper program lookup, virito-net ABI check and FDC capabilities
by Peter Krempa 30 May '25

30 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- v2: - moved the entry about $PATH lookup under "packaging changes" - added a note that it fixes libvirt on distros which merged /sbin to /bin but only on new installs NEWS.rst | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index fd577021b3..d1bb19c8db 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -21,6 +21,25 @@ v11.4.0 (unreleased) Support for the recently released IBM POWER11 processor was added. +* **Packaging changes** + + * All helper programs are now detected from ``$PATH`` during runtime + + All of the code was now converted to dynamically look up helper programs + in ``$PATH`` rather than doing the lookup at build time and then compiling + in the result. + + Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``, + ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``, + ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``, + ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the + tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not + needed during build and will still work properly if placed in ``$PATH``. + + This also ensures that libvirt works correctly on distros that are + transitioning ``/sbin`` into ``/bin`` and upgraded installations have + a different layout from fresh installations. + * **Improvements** * virsh: Add option ``--no-pkttyagent`` @@ -35,6 +54,11 @@ v11.4.0 (unreleased) <nvram/> </os> + * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML + + The data is now based on the presence of the controller in qemu rather than + just a denylist of machine types where floppies not work. + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots @@ -52,6 +76,13 @@ v11.4.0 (unreleased) destination host to crash when trying to resume failed post-copy migration. + * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI + + The queue count itself isn't a device frontend property but libvirt uses + it to calculate ``vectors`` option of the device which is a guest OS visible + property, thus ``queues`` must not change during migration. The ABI stability + check now handles this properly. + v11.3.0 (2025-05-02) ==================== -- 2.49.0

2 1

Plans for 11.4.0 release (freeze on 2025-05-27)
by Jiri Denemark 30 May '25

30 May '25

We are getting close to 11.4.0 release of libvirt. To aim for the release on Monday 02 Jun I suggest entering the freeze on Tuesday 27 May and tagging RC2 on Friday 30 May. I hope this works for everyone. Jirka

1 1

[PATCH] virConnectAuthCallbackDefault: Return failure if 'virGetPassword' returns NULL
by Peter Krempa 29 May '25

29 May '25

From: Peter Krempa <pkrempa(a)redhat.com> virGetPassword can return NULL on linux or BSD if it fails. The caller in virConnectAuthCallbackDefault does dereference it unconditionally. Return failure if virGetPassword returns NULL. Fixes: db72866310d1e520efa8ed2d4589bdb5e76a1c95 Closes: https://gitlab.com/libvirt/libvirt/-/issues/777 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/libvirt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/libvirt.c b/src/libvirt.c index 581fc6deea..375d3fa7ef 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -158,7 +158,9 @@ virConnectAuthCallbackDefault(virConnectCredentialPtr cred, if (fflush(stdout) != 0) return -1; - bufptr = virGetPassword(); + if (!(bufptr = virGetPassword())) + return -1; + if (STREQ(bufptr, "")) VIR_FREE(bufptr); break; -- 2.49.0

2 1

[PATCH] NEWS: Mention removal of compile time helper program lookup, virito-net ABI check and FDC capabilities
by Peter Krempa 29 May '25

29 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- NEWS.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index fd577021b3..884fcad2d8 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -35,6 +35,24 @@ v11.4.0 (unreleased) <nvram/> </os> + * All helper programs are now detected from ``$PATH`` during runtime + + All of the code was now converted to dynamically look up helper programs + in ``$PATH`` rather than doing the lookup at build time and then compiling + in the result. + + Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``, + ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``, + ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``, + ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the + tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not + needed during build and will still work properly if placed in ``$PATH``. + + * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML + + The data is now based on the presence of the controller in qemu rather than + just a denylist of machine types where floppies not work. + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots @@ -52,6 +70,13 @@ v11.4.0 (unreleased) destination host to crash when trying to resume failed post-copy migration. + * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI + + The queue count itself isn't a device frontend property but libvirt uses + it to calculate ``vectors`` option of the device which is a guest OS visible + property, thus ``queues`` must not change during migration. The ABI stability + check now handles this properly. + v11.3.0 (2025-05-02) ==================== -- 2.49.0

2 2

[PATCH 0/3] util: Fix virFileIsSharedFSOverride on nonexistent paths
by Jiri Denemark 29 May '25

29 May '25

Jiri Denemark (3): util: Document limitation of virFileCanonicalizePath util: Introduce virFileGetExistingParent helper util: Fix virFileIsSharedFSOverride on nonexistent paths src/util/virfile.c | 76 +++++++++++++++++++++++++++------------------- 1 file changed, 45 insertions(+), 31 deletions(-) -- 2.49.0

2 4

[PATCH 00/15] storage_file_probe: Fix ancient bug in qcow2 header extensions parser and refactor the image probing callbacks
by Peter Krempa 29 May '25

29 May '25

Patch 3 fixes an almost 15 year old bug in the qcow2 header extension parser which breaks when the qcow2 image has more than 1 header extension. For us it caused problems for qcow2 images with data file and backing file which we didn't use before, and the only field we cared about was always put first by qemu. Ironically we did have a test file that had such config but it was missed in the test output. Patches 1, 2 are refinment of debug tools I used to see what's happening. Patch 4 adds bitmaps to some test images. We don't parse them but just to be sure. The rest of the series refactors the metadata parser callbacks with the end goal to not parse the qcow2 header extensions twice. Peter Krempa (15): qcow2GetExtensions: Add debug logs for interesting fields in qcow2 header extension parser virstoragetest: Reformat output to hilight dataFile relationship storage_file_probe: qcow2GetExtensions: Fix qcow2 header extension parsing virstoragetest: Add qcow2 bitmaps to some images storage_file_probe: Add image specific callback taking the whole virStorageSource storage_file_probe: Refactor cowGetBackingStore into cowGetImageSpecific storage_file_probe: Refactor qedGetBackingStore into qedGetImageSpecific storage_file_probe: Refactor vmdk4GetBackingStore into vmdk4GetImageSpecific storage_file_probe: Refactor qcowXGetBackingStore into specific callbacks for qcow and qcow2 storage_file_probe: Move logic from qcow2GetClusterSize to qcow2GetImageSpecific storage_file_probe: Move qcow2GetFeatures(ProcessGroup) functions storage_file_probe: Call qcow2GetFeatures from qcow2GetImageSpecific storage_file_probe: Parse all qcow2 extensions at once storage_file_probe: Move setting of 'compat' attribute to qcow2GetFeatures storage_file_probe: Remove unused image probing callbacks src/storage_file/storage_file_probe.c | 439 ++++++++---------- tests/virstoragetest.c | 20 +- .../virstoragetestdata/images/datafile.qcow2 | Bin 327680 -> 393256 bytes .../images/qcow2_qcow2-qcow2_qcow2-auto.qcow2 | Bin 196616 -> 327720 bytes .../images/qcow2datafile-datafile.qcow2 | Bin 196616 -> 327720 bytes tests/virstoragetestdata/out/directory-dir | 1 + tests/virstoragetestdata/out/directory-none | 1 + tests/virstoragetestdata/out/directory-raw | 1 + .../out/qcow2-auto_qcow2-qcow2_raw-raw | 1 + .../out/qcow2-auto_raw-raw-relative | 1 + tests/virstoragetestdata/out/qcow2-datafile | 15 +- .../out/qcow2-protocol-backing-file | 2 + .../out/qcow2-protocol-backing-nbd | 2 + .../out/qcow2-qcow2_nbd-raw | 2 + .../out/qcow2-qcow2_qcow2-auto | 2 + .../out/qcow2-qcow2_qcow2-qcow2_qcow2-auto | 3 + .../out/qcow2-qcow2_qcow2-qcow2_raw-auto | 3 + .../out/qcow2-qcow2_qcow2-qcow2_raw-raw | 3 + .../out/qcow2-qcow2_raw-raw-relative | 2 + tests/virstoragetestdata/out/qcow2-symlinks | 3 + .../out/qcow2datafile-qcow2_qcow2-datafile | 24 +- tests/virstoragetestdata/out/qed-auto_raw | 1 + tests/virstoragetestdata/out/qed-qed_raw | 2 + tests/virstoragetestdata/out/raw-auto | 1 + tests/virstoragetestdata/out/raw-raw | 1 + 25 files changed, 263 insertions(+), 267 deletions(-) -- 2.49.0

2 20

[PATCH 0/3] bhyve: implement domainInterfaceStats and domainMemoryStats
by Roman Bogorodskiy 29 May '25

29 May '25

Roman Bogorodskiy (3): bhyve: implement domainInterfaceStats virprocess: implement virProcessGetStatInfo() for FreeBSD bhyve: implement domainMemoryStats src/bhyve/bhyve_driver.c | 84 +++++++++++++++++++++++++++++++ src/util/virprocess.c | 104 +++++++++++++++++++++++++++++---------- 2 files changed, 162 insertions(+), 26 deletions(-) -- 2.49.0

1 3