November 2025 - Devel - libvirt List Archives

[PATCH 0/4] qemucapabilitiestest: Update x86_64 caps, prepare
by Peter Krempa 25 Nov '25

25 Nov '25

Patch 1 updates the x86_64 dump to last state. Patches 2,3 get rid of explicit use of virt-4.0 and 4.2 machines on aarch64 which will be dropped. Patch 4 adds a dev-cycle dump for aarch64 collected on a raspberry pi. Normally I wouldn't add one so close to the release but Jano asked me for some of his patches. Treat patch 4 as RFC. Additionally if anyone wants to contribute dump from a better machine please do so. Peter Krempa (4): qemucapabilitiestest: qemucapabilitiestest: Update 'caps_10.2.0_x86_64' to 'v10.2.0-rc1-38-gfb241d0a1f' qemuxmlconftest: Update 'aarch64' tests using 'virt-4.0' machine type qemuxmlconftest: Update 'aarch64' tests using 'virt-4.2' machine type qemucapabilitiestest: Add data for the qemu-10.2 dev cycle for 'aarch64' .../qemu_10.2.0-virt.aarch64.xml | 249 + tests/domaincapsdata/qemu_10.2.0.aarch64.xml | 249 + .../caps_10.2.0_aarch64.replies | 39126 ++++++++++++++++ .../caps_10.2.0_aarch64.xml | 530 + .../caps_10.2.0_x86_64.replies | 24 +- .../caps_10.2.0_x86_64.xml | 4 +- ...arch64-cpu-passthrough.aarch64-latest.args | 2 +- ...aarch64-cpu-passthrough.aarch64-latest.xml | 2 +- ...ault-cpu-kvm-virt-10.0.aarch64-latest.args | 35 + ...fault-cpu-kvm-virt-10.0.aarch64-latest.xml | 39 + .../aarch64-default-cpu-kvm-virt-10.0.xml | 20 + ...ault-cpu-kvm-virt-4.2.aarch64-10.0.0.args} | 0 ...fault-cpu-kvm-virt-4.2.aarch64-10.0.0.xml} | 0 ...ault-cpu-tcg-virt-10.0.aarch64-latest.args | 35 + ...fault-cpu-tcg-virt-10.0.aarch64-latest.xml | 39 + .../aarch64-default-cpu-tcg-virt-10.0.xml | 20 + ...ault-cpu-tcg-virt-4.2.aarch64-10.0.0.args} | 0 ...fault-cpu-tcg-virt-4.2.aarch64-10.0.0.xml} | 0 ...aarch64-features-pauth.aarch64-latest.args | 2 +- .../aarch64-features-pauth.aarch64-latest.xml | 2 +- .../aarch64-features-sve.aarch64-latest.args | 2 +- .../aarch64-features-sve.aarch64-latest.xml | 2 +- .../aarch64-features-wrong.aarch64-latest.xml | 2 +- .../aarch64-gic-default.aarch64-latest.args | 2 +- .../aarch64-gic-default.aarch64-latest.xml | 2 +- .../aarch64-gic-none.aarch64-latest.args | 2 +- .../aarch64-gic-none.aarch64-latest.xml | 2 +- .../aarch64-kvm-32-on-64.aarch64-latest.args | 2 +- .../aarch64-kvm-32-on-64.aarch64-latest.xml | 2 +- .../aarch64-pci-serial.aarch64-latest.args | 1 - .../aarch64-pci-serial.aarch64-latest.xml | 3 - ...arch64-traditional-pci.aarch64-latest.args | 1 - ...aarch64-traditional-pci.aarch64-latest.xml | 3 - ...aarch64-usb-controller.aarch64-latest.args | 1 - .../aarch64-usb-controller.aarch64-latest.xml | 3 - ...ault-models.aarch64-latest.abi-update.args | 1 - ...fault-models.aarch64-latest.abi-update.xml | 3 - ...64-virt-default-models.aarch64-latest.args | 1 - ...h64-virt-default-models.aarch64-latest.xml | 3 - .../aarch64-virt-graphics.aarch64-latest.args | 3 +- .../aarch64-virt-graphics.aarch64-latest.xml | 5 +- .../qemuxmlconfdata/aarch64-virt-graphics.xml | 2 +- ...h64-virt-headless-mmio.aarch64-latest.args | 3 +- ...ch64-virt-headless-mmio.aarch64-latest.xml | 5 +- .../aarch64-virt-headless-mmio.xml | 2 +- .../aarch64-virt-headless.aarch64-latest.args | 3 +- .../aarch64-virt-headless.aarch64-latest.xml | 5 +- .../qemuxmlconfdata/aarch64-virt-headless.xml | 2 +- ...irt-minimal.aarch64-latest.abi-update.args | 1 - ...virt-minimal.aarch64-latest.abi-update.xml | 3 - .../aarch64-virt-minimal.aarch64-latest.args | 1 - .../aarch64-virt-minimal.aarch64-latest.xml | 3 - .../arm-vexpressa9-basic.aarch64-latest.args | 1 + .../arm-vexpressa9-basic.aarch64-latest.xml | 3 + .../arm-vexpressa9-nodevs.aarch64-latest.args | 1 + .../arm-vexpressa9-nodevs.aarch64-latest.xml | 3 + .../arm-vexpressa9-virtio.aarch64-latest.args | 1 + .../arm-vexpressa9-virtio.aarch64-latest.xml | 3 + .../cpu-topology5.aarch64-latest.args | 1 - .../cpu-topology5.aarch64-latest.xml | 3 +- ...ult-video-type-aarch64.aarch64-latest.args | 2 +- ...ault-video-type-aarch64.aarch64-latest.xml | 2 +- .../disk-arm-virtio-sd.aarch64-latest.args | 1 + .../disk-arm-virtio-sd.aarch64-latest.xml | 3 + ...efi-aarch64.aarch64-latest.abi-update.args | 3 +- ...-efi-aarch64.aarch64-latest.abi-update.xml | 5 +- ...mware-auto-efi-aarch64.aarch64-latest.args | 3 +- ...rmware-auto-efi-aarch64.aarch64-latest.xml | 5 +- .../firmware-auto-efi-aarch64.xml | 2 +- ...-loader-raw.aarch64-latest.abi-update.args | 3 +- ...t-loader-raw.aarch64-latest.abi-update.xml | 5 +- ...-efi-format-loader-raw.aarch64-latest.args | 3 +- ...o-efi-format-loader-raw.aarch64-latest.xml | 5 +- .../firmware-auto-efi-format-loader-raw.xml | 2 +- ...i-aarch64-legacy-paths.aarch64-latest.args | 3 +- ...fi-aarch64-legacy-paths.aarch64-latest.xml | 5 +- ...rmware-manual-efi-aarch64-legacy-paths.xml | 2 +- ...anual-efi-acpi-aarch64.aarch64-latest.args | 3 +- ...manual-efi-acpi-aarch64.aarch64-latest.xml | 5 +- .../firmware-manual-efi-acpi-aarch64.xml | 2 +- ...ual-efi-noacpi-aarch64.aarch64-latest.args | 3 +- ...nual-efi-noacpi-aarch64.aarch64-latest.xml | 5 +- .../firmware-manual-efi-noacpi-aarch64.xml | 2 +- .../firmware-manual-noefi-acpi-aarch64.xml | 2 +- ...l-noefi-noacpi-aarch64.aarch64-latest.args | 3 +- ...al-noefi-noacpi-aarch64.aarch64-latest.xml | 5 +- .../firmware-manual-noefi-noacpi-aarch64.xml | 2 +- .../iommu-smmuv3-pci-bus.aarch64-latest.args | 1 - .../iommu-smmuv3-pci-bus.aarch64-latest.xml | 3 - .../iommu-smmuv3.aarch64-latest.args | 1 - .../iommu-smmuv3.aarch64-latest.xml | 3 - ...ch-virt-console-native.aarch64-latest.args | 1 - ...ach-virt-console-native.aarch64-latest.xml | 3 - ...ch-virt-console-virtio.aarch64-latest.args | 1 - ...ach-virt-console-virtio.aarch64-latest.xml | 3 - ...-serial+console-native.aarch64-latest.args | 1 - ...t-serial+console-native.aarch64-latest.xml | 3 - ...ach-virt-serial-compat.aarch64-latest.args | 1 - ...mach-virt-serial-compat.aarch64-latest.xml | 3 - ...ach-virt-serial-native.aarch64-latest.args | 1 - ...mach-virt-serial-native.aarch64-latest.xml | 3 - .../mach-virt-serial-pci.aarch64-latest.args | 1 - .../mach-virt-serial-pci.aarch64-latest.xml | 3 - .../mach-virt-serial-usb.aarch64-latest.args | 1 - .../mach-virt-serial-usb.aarch64-latest.xml | 3 - ...e-expander-bus-aarch64.aarch64-latest.args | 1 - ...ie-expander-bus-aarch64.aarch64-latest.xml | 3 - .../pcihole64-virt.aarch64-latest.args | 1 - .../pcihole64-virt.aarch64-latest.xml | 3 - .../pvpanic-pci-aarch64.aarch64-latest.args | 1 - .../pvpanic-pci-aarch64.aarch64-latest.xml | 3 - ...pci-no-address-aarch64.aarch64-latest.args | 1 - ...-pci-no-address-aarch64.aarch64-latest.xml | 3 - ...automatic-virt-aarch64.aarch64-latest.args | 1 - ...-automatic-virt-aarch64.aarch64-latest.xml | 3 - ...-fallback-virt-aarch64.aarch64-latest.args | 1 - ...t-fallback-virt-aarch64.aarch64-latest.xml | 3 - ...r-default-virt-aarch64.aarch64-latest.args | 1 - ...er-default-virt-aarch64.aarch64-latest.xml | 3 - .../virtio-iommu-aarch64.aarch64-latest.args | 1 - .../virtio-iommu-aarch64.aarch64-latest.xml | 3 - tests/qemuxmlconftest.c | 6 +- 122 files changed, 40428 insertions(+), 202 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.2.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_aarch64.xml create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-kvm-virt-10.0.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-kvm-virt-10.0.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-kvm-virt-10.0.xml rename tests/qemuxmlconfdata/{aarch64-default-cpu-kvm-virt-4.2.aarch64-latest.args => aarch64-default-cpu-kvm-virt-4.2.aarch64-10.0.0.args} (100%) rename tests/qemuxmlconfdata/{aarch64-default-cpu-kvm-virt-4.2.aarch64-latest.xml => aarch64-default-cpu-kvm-virt-4.2.aarch64-10.0.0.xml} (100%) create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-10.0.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-10.0.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-10.0.xml rename tests/qemuxmlconfdata/{aarch64-default-cpu-tcg-virt-4.2.aarch64-latest.args => aarch64-default-cpu-tcg-virt-4.2.aarch64-10.0.0.args} (100%) rename tests/qemuxmlconfdata/{aarch64-default-cpu-tcg-virt-4.2.aarch64-latest.xml => aarch64-default-cpu-tcg-virt-4.2.aarch64-10.0.0.xml} (100%) -- 2.51.1

3 11

[PATCH v3] spec: Fix 'libvirt-daemon-driver-storage-zfs' on Fedora 43 and newer
by Peter Krempa 25 Nov '25

25 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit bd30147e740 added an 'Obsoletes' directive so that the storage driver core package will update properly but hardcoded the obsoleted version as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd packages and disabled the build. Now it is still possible to obtain ZFS support from other means and it may be useful for users to have libvirt's ZFS backend. This patch thus: - re-enables build of 'libvirt-daemon-driver-storage-zfs' on Fedora - removes 'libvirt-daemon-driver-storage-zfs' as 'Requires dependency from 'daemon-driver-storage' meta-package on Fedora 43 and newer - removes dependancy on '/sbin/zpool' and '/sbin/zfs' on Fedora 43 and newer With this the package still is built and installable but will require users to get their ZFS support installed somehow. Fixes: bd30147e740d49fdb5844160e480ca34611f75e5 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- libvirt.spec.in | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) Remove the dependency on the programs too. diff --git a/libvirt.spec.in b/libvirt.spec.in index 8314fbeb34..62af7fb517 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -76,8 +76,10 @@ %define with_storage_gluster 0 %endif -# Fedora had zfs-fuse until F43 -%if 0%{?fedora} && 0%{?fedora} < 43 +# On Fedora 43, the 'zfs-fuse' package was removed, but is obtainable via +# other means. Build the backend, but it's no longer considered to be part +# of 'daemon-driver-storage'. +%if 0%{?fedora} %define with_storage_zfs 0%{!?_without_storage_zfs:1} %else %define with_storage_zfs 0 @@ -667,9 +669,6 @@ Requires: /usr/bin/qemu-img Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0 %endif Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0 - %if !%{with_storage_zfs} -Obsoletes: libvirt-daemon-driver-storage-zfs < 11.4.0 - %endif %description daemon-driver-storage-core The storage driver plugin for the libvirtd daemon, providing @@ -770,9 +769,13 @@ volumes using the ceph protocol. Summary: Storage driver plugin for ZFS Requires: libvirt-daemon-driver-storage-core = %{version}-%{release} Requires: libvirt-libs = %{version}-%{release} -# Support any conforming implementation of zfs +# Starting with Fedora 43 the 'zfs-fuse' is no longer shipped but obtainable +# externally. The package builds fine without these. Users will have to provide +# their own implementation. + %if 0%{?fedora} && 0%{?fedora} < 43 Requires: /sbin/zfs Requires: /sbin/zpool + %endif %description daemon-driver-storage-zfs The storage driver backend adding implementation of the storage APIs for @@ -796,7 +799,10 @@ Requires: libvirt-daemon-driver-storage-gluster = %{version}-%{release} %if %{with_storage_rbd} Requires: libvirt-daemon-driver-storage-rbd = %{version}-%{release} %endif - %if %{with_storage_zfs} +# Starting with Fedora 43 the 'zfs-fuse' is no longer shipped but obtainable +# externally. We do not want to install this as part of 'daemon-driver-storage' +# any more. + %if %{with_storage_zfs} && 0%{?fedora} && 0%{?fedora} < 43 Requires: libvirt-daemon-driver-storage-zfs = %{version}-%{release} %endif -- 2.51.1

3 4

[PATCH] src: fix incorrect build conditional for KVM MSR code
by Daniel P. Berrangé 25 Nov '25

25 Nov '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The condition WITH_LINUX_KVM_H && (defined(__linux__) || defined(__FreeBSD__)) is redundant. If the meson check for linux/kvm.h succeeded, we must be on a Linux host and cannot be on a FreeBSD host. Remove these redundant OS conditions from the MSR code. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/util/virhostcpu.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index c3b4f87de1..09395ddb04 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1328,8 +1328,7 @@ virHostCPUGetMicrocodeVersion(virArch hostArch G_GNUC_UNUSED) #if WITH_LINUX_KVM_H && defined(KVM_GET_MSRS) && \ - (defined(__i386__) || defined(__x86_64__)) && \ - (defined(__linux__) || defined(__FreeBSD__)) + (defined(__i386__) || defined(__x86_64__)) static int virHostCPUGetMSRFromKVM(unsigned long index, uint64_t *result) @@ -1585,8 +1584,7 @@ virHostCPUGetTscInfo(void) } #endif /* WITH_LINUX_KVM_H && defined(KVM_GET_MSRS) && \ - (defined(__i386__) || defined(__x86_64__)) && \ - (defined(__linux__) || defined(__FreeBSD__)) */ + (defined(__i386__) || defined(__x86_64__)) */ int virHostCPUReadSignature(virArch arch, -- 2.51.1

2 2

[PATCH 0/2] Validate 'removable' and support 'dpofua' properties of SCSI disks
by Peter Krempa 24 Nov '25

24 Nov '25

Patch 1 adds a missing ABI stability check for 'removable' and patch 2 implements 'dpofua' for SCSI disks. Peter Krempa (2): virDomainDiskDefCheckABIStability: Add missing check for 'removable' property Add support for 'dpofua' setting for SCSI disks docs/formatdomain.rst | 5 ++++ src/conf/domain_conf.c | 23 +++++++++++++++++++ src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 7 ++++++ src/conf/schemas/domaincommon.rng | 5 ++++ src/qemu/qemu_command.c | 1 + .../disk-scsi.x86_64-latest.args | 4 ++-- .../disk-scsi.x86_64-latest.xml | 4 ++-- tests/qemuxmlconfdata/disk-scsi.xml | 4 ++-- 9 files changed, 48 insertions(+), 6 deletions(-) -- 2.51.1

2 3

[PATCH v2] spec: Fix 'libvirt-daemon-driver-storage-zfs' on Fedora 43 and newer
by Peter Krempa 24 Nov '25

24 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit bd30147e740 added an 'Obsoletes' directive so that the storage driver core package will update properly but hardcoded the obsoleted version as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd packages and disabled the build. Now it is still possible to obtain ZFS support from other means and it may be useful for users to have libvirt's ZFS backend. This patch thus: - re-enables build of 'libvirt-daemon-driver-storage-zfs' on Fedora - removes 'libvirt-daemon-driver-storage-zfs' as 'Requires dependency from 'daemon-driver-storage' meta-package on Fedora 43 and newer With this the package still is built and installable but will require users to get their ZFS support installed somehow. Fixes: bd30147e740d49fdb5844160e480ca34611f75e5 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- libvirt.spec.in | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) I originally thought that the 'Requires' dependancy requiring /sbin/zpool and /sbin/zfs would need to be dropped but even without 'zfs-fuse' on F43 it builds fine. diff --git a/libvirt.spec.in b/libvirt.spec.in index 8314fbeb34..1bfe7d715b 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -76,8 +76,10 @@ %define with_storage_gluster 0 %endif -# Fedora had zfs-fuse until F43 -%if 0%{?fedora} && 0%{?fedora} < 43 +# On Fedora 43, the 'zfs-fuse' package was removed, but is obtainable via +# other means. Build the backend, but it's no longer considered to be part +# of 'daemon-driver-storage'. +%if 0%{?fedora} %define with_storage_zfs 0%{!?_without_storage_zfs:1} %else %define with_storage_zfs 0 @@ -667,9 +669,6 @@ Requires: /usr/bin/qemu-img Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0 %endif Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0 - %if !%{with_storage_zfs} -Obsoletes: libvirt-daemon-driver-storage-zfs < 11.4.0 - %endif %description daemon-driver-storage-core The storage driver plugin for the libvirtd daemon, providing @@ -796,7 +795,10 @@ Requires: libvirt-daemon-driver-storage-gluster = %{version}-%{release} %if %{with_storage_rbd} Requires: libvirt-daemon-driver-storage-rbd = %{version}-%{release} %endif - %if %{with_storage_zfs} +# Starting with Fedora 43 the 'zfs-fuse' is no longer shipped but obtainable +# externally. We do not want to install this as part of 'daemon-driver-storage' +# any more. + %if %{with_storage_zfs} && 0%{?fedora} && 0%{?fedora} < 43 Requires: libvirt-daemon-driver-storage-zfs = %{version}-%{release} %endif -- 2.51.1

2 1

[RFC PATCH v7 0/3] Fix virtio console port assignment issue
by Aaron M. Brown 24 Nov '25

24 Nov '25

Changelog: --- v7: - Removed some unnecessary definitions from test xml - Moved edge case reservation logic to virDomainVirtioSerialAddrAssign --- v6: - Fixed issue with console auto port index starting from 1 instead of 0 --- v5: - Added xml tests to tests/qemuxmlconfdata - Fixed virito -> virtio typo in commit message --- v4: - Update commit messages --- v3: - Added Reviewed-By - Included CI Results Link --- v2: - Split patch into two commits - Added fixes tag --- This libvirt patch series does the following: 1. fixes an issue with virtio console device port auto assignment on virtio-serial buses 2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity 3. Adds tests for virtio console on the vioserial bus Currently in libvirt, a virtio console device cannot be auto assigned a port number greater than zero on a virtio-serial bus. This leads to port collision errors when adding more than 1 virtio console device on a single virtio-serial bus. After applying this patch, one can add multiple console ports under a single virtio-serial bus. Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/2047914492 Aaron M. Brown (3): tests: Add console-virtio-serial-autoassign-address tests domain_addr.c: Fix virtio console port autoassign on virtio-serial bus domain_addr.c: update virtconsole port reservation comment and allowZero var src/conf/domain_addr.c | 51 +++++++++++++----- ...rial-autoassign-address.x86_64-latest.args | 42 +++++++++++++++ ...erial-autoassign-address.x86_64-latest.xml | 54 +++++++++++++++++++ ...nsole-virtio-serial-autoassign-address.xml | 40 ++++++++++++++ tests/qemuxmlconftest.c | 1 + 5 files changed, 175 insertions(+), 13 deletions(-) create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/console-virtio-serial-autoassign-address.xml -- 2.39.5 (Apple Git-154)

4 10

[PATCH v2 0/3] qemu: fix capabilities reporting for TDX
by Daniel P. Berrangé 24 Nov '25

24 Nov '25

The capabilities reporting merged for TDX was flawed because it would always report TDX as supported simply if QEMU was new enough to have 'tdx-guest'. Unfortunately the 'query-tdx-capabilities' QMP command that was in early postings: https://mail.gnu.org/archive/html/qemu-devel/2021-07/msg01689.html went missing and I'm not seeing an alternative way to query QEMU to see if TDX is actually launchable. So in these patches I open /dev/kvm and directly ask of the 'TDX' VM type is supported by KVM, which IIUC is equivalent to waht the original 'query-tdx-capabilities' patch was doing. In v2: * Unconditionally report TDX on all arches * Also unconditionally report s390 prot-virt on all arches * Use VIR_AUTOCLOSE * Sanity check ioctl return status < 0 * Remove dead error reporting paths * Add missing ioctl.h header include Daniel P. Berrangé (3): qemu: correctly detect working TDX support qemu: always report TDX feature caps on x86 qemu: always report s390 prot-virt feature in domain caps src/qemu/qemu_capabilities.c | 70 ++++++++++++++++--- src/qemu/qemu_capabilities.h | 3 + .../qemu_10.0.0-q35.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 2 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 2 + .../qemu_10.0.0-virt.aarch64.xml | 2 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 2 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 2 + .../qemu_10.1.0-q35.x86_64+inteltdx.xml | 1 + .../domaincapsdata/qemu_10.1.0-q35.x86_64.xml | 1 + .../qemu_10.1.0-tcg.x86_64+inteltdx.xml | 2 + .../domaincapsdata/qemu_10.1.0-tcg.x86_64.xml | 2 + .../qemu_10.1.0.x86_64+inteltdx.xml | 1 + tests/domaincapsdata/qemu_10.1.0.x86_64.xml | 1 + .../qemu_10.2.0-q35.x86_64+mshv.xml | 1 + .../domaincapsdata/qemu_10.2.0-q35.x86_64.xml | 1 + .../qemu_10.2.0-tcg.x86_64+mshv.xml | 2 + .../domaincapsdata/qemu_10.2.0-tcg.x86_64.xml | 2 + .../qemu_10.2.0.x86_64+mshv.xml | 1 + tests/domaincapsdata/qemu_10.2.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 2 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 2 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 2 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 2 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 2 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 2 + .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 2 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 2 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_8.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 2 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 2 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 2 + .../qemu_8.2.0-virt.aarch64.xml | 2 + .../qemu_8.2.0-virt.loongarch64.xml | 2 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_9.0.0.sparc.xml | 2 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 2 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 2 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 2 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 2 + .../qemu_9.1.0-virt.riscv64.xml | 2 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 2 + .../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 2 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 2 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 2 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 2 + tests/domaincapsmock.c | 6 ++ 77 files changed, 205 insertions(+), 9 deletions(-) -- 2.51.1

2 7

[PATCH v1 0/4] s390x CPU Models: Fix deprecated_features='on'
by Collin Walling 24 Nov '25

24 Nov '25

Currently, when setting the deprecated_features attribute to 'on', all known deprecated features will be enabled for the CPU model, including ones that are *not* supported by the model. These patches query an additional set of deprecated features by performing a CPU model expansion on host-model with type "static". The list of deprecated features reported from this command will reflect features that may be enabled on the model without error. Now, when a user specifies deprecated_features='on' in the domain XML, only the features that are still supported by the model are requested to be turned on for the guest. This can be helpful for e.g. tests that may wish to check CPU model compatability in certain environments. Collin Walling (4): qemu: rename modelinfo's deprecated_props to full_dep_props qemu: refactor load/format of deprecated features qemu: query and cache static/host deprecated features qemu: only allow enabling deprecated features that are supported src/qemu/qemu_capabilities.c | 106 ++++++++++++------ src/qemu/qemu_monitor.c | 6 +- src/qemu/qemu_monitor.h | 3 +- src/qemu/qemu_monitor_json.c | 17 ++- .../caps_10.0.0_s390x.xml | 6 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 6 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 6 + 7 files changed, 112 insertions(+), 38 deletions(-) -- 2.51.1

3 9

[PATCH] spec: Fix 'obsoletes' for 'libvirt-daemon-driver-storage-zfs'
by Peter Krempa 24 Nov '25

24 Nov '25

From: Peter Krempa <pkrempa(a)redhat.com> On Fedora 43 and newer the 'fuse-zfs' package was removed. Commit bd30147e740 added an 'Obsoletes' directive so that the storage driver core package will update properly but hardcoded the obsoleted version as 11.4 (when the change was comitted) similarly to the old sheepdog/rbd packages. Unfortunately that doesn't work if the sub-package removal happened based on an external dependancy, rather than complete removal of said module in libvirt. If users have e.g. virt-preview repos enabled they'll get libvirt-11.9 currently installed, but the obsoleted version is just 11.4, thus upgrades to Fedora 43 with virt-preview are broken. Fix this by obsoleting everything up to the current build. Fixes: bd30147e740d49fdb5844160e480ca34611f75e5 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 8314fbeb34..f1bfd5e652 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -668,7 +668,7 @@ Obsoletes: libvirt-daemon-driver-storage-rbd < 5.2.0 %endif Obsoletes: libvirt-daemon-driver-storage-sheepdog < 8.8.0 %if !%{with_storage_zfs} -Obsoletes: libvirt-daemon-driver-storage-zfs < 11.4.0 +Obsoletes: libvirt-daemon-driver-storage-zfs <= %{version}-%{release} %endif %description daemon-driver-storage-core -- 2.51.1

3 7

[PATCH] src: cap the data size in stream I/O functions
by Daniel P. Berrangé 24 Nov '25

24 Nov '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The main stream I/O functions have a design flaw in that they accept 'size_t' as the input data length, while intending to return the amount actually processed in an 'int'. Fortunately all functions explicitly document that less data may be processed than requested, and with the remote driver data cap we will never get anywhere near exceeding an 'int' even on 32-bit. For sanity, however, lets explicitly cap the data size in the public API to fix the design flaw. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/libvirt-stream.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/src/libvirt-stream.c b/src/libvirt-stream.c index ca4d90140e..61c700c19e 100644 --- a/src/libvirt-stream.c +++ b/src/libvirt-stream.c @@ -182,6 +182,15 @@ virStreamSend(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes = G_MAXINT32; + } + if (stream->driver && stream->driver->streamSend) { int ret; @@ -279,6 +288,15 @@ virStreamRecv(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes = G_MAXINT32; + } + if (stream->driver && stream->driver->streamRecv) { int ret; @@ -370,6 +388,15 @@ virStreamRecvFlags(virStreamPtr stream, virCheckStreamReturn(stream, -1); virCheckNonNullArgGoto(data, error); + /* + * We accept size_t which could be 2^64-1, but we need to return + * bytes processed in a signed int, so must cap the request to + * fit in a 'signed int' on a 32-bit platform. + */ + if (nbytes > G_MAXINT32) { + nbytes = G_MAXINT32; + } + if (stream->driver && stream->driver->streamRecvFlags) { int ret; -- 2.51.1

2 1