May 2025 - Devel - libvirt List Archives

[PATCH v2 0/4] domain_capabilities: add console capabilities
by Roman Bogorodskiy 26 May '25

26 May '25

Main change since v1 is adding console capabilities reporting for the libxl driver. There's also a minor cosmetic change in the qemu part to alphabetically sort VIR_DOMAIN_CHR_TYPE_* arguments for VIR_DOMAIN_CAPS_ENUM_SET(). Apparently, the only other driver reporting domain capabilities is the test driver, so it looks like all drivers are covered by this series. Roman Bogorodskiy (4): domain_capabilities: add console capabilities bhyve: capabilities: report NMDM console qemu: capabilities: report supported console types libxl: capabilities: report supported console types src/bhyve/bhyve_capabilities.c | 5 +++ src/conf/domain_capabilities.c | 12 +++++++ src/conf/domain_capabilities.h | 8 +++++ src/conf/schemas/domaincaps.rng | 10 ++++++ src/libxl/libxl_capabilities.c | 23 ++++++++++++- src/qemu/qemu_capabilities.c | 32 +++++++++++++++++++ src/qemu/qemu_capabilities.h | 3 ++ tests/domaincapsdata/bhyve_basic.x86_64.xml | 5 +++ tests/domaincapsdata/bhyve_fbuf.x86_64.xml | 5 +++ tests/domaincapsdata/bhyve_uefi.x86_64.xml | 5 +++ tests/domaincapsdata/libxl-xenfv.xml | 13 ++++++++ tests/domaincapsdata/libxl-xenpv.xml | 13 ++++++++ .../qemu_10.0.0-q35.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_10.0.0-virt.aarch64.xml | 15 +++++++++ tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 15 +++++++++ tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_10.0.0.s390x.xml | 15 +++++++++ .../qemu_10.0.0.x86_64+amdsev.xml | 18 +++++++++++ tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 15 +++++++++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 18 +++++++++++ .../qemu_7.2.0-hvf.x86_64+hvf.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_7.2.0-tcg.x86_64+hvf.xml | 18 +++++++++++ .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.2.0.ppc.xml | 18 +++++++++++ tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.1.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_8.2.0-tcg-virt.loongarch64.xml | 18 +++++++++++ .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_8.2.0-virt.aarch64.xml | 16 ++++++++++ .../qemu_8.2.0-virt.loongarch64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 16 ++++++++++ tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 18 +++++++++++ tests/domaincapsdata/qemu_8.2.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.0.0.sparc.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_9.1.0-tcg-virt.riscv64.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 18 +++++++++++ .../qemu_9.1.0-virt.riscv64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.1.0.s390x.xml | 15 +++++++++ tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 18 +++++++++++ .../qemu_9.2.0-hvf.aarch64+hvf.xml | 16 ++++++++++ .../qemu_9.2.0-q35.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 18 +++++++++++ .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 18 +++++++++++ .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.2.0.s390x.xml | 15 +++++++++ .../qemu_9.2.0.x86_64+amdsev.xml | 18 +++++++++++ tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 18 +++++++++++ 74 files changed, 1213 insertions(+), 1 deletion(-) -- 2.49.0

2 5

[PATCH v3 0/2] Fix virtio console port assignment issue
by Aaron M. Brown 22 May '25

22 May '25

Changelog: --- v3: - Added Reviewed-By - Included CI Results Link --- v2: - Split patch into two commits - Added fixes tag --- This libvirt patch does the following: 1. fixes an issue with virtio console device port assignment on vioserial buses 2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity Currently in libvirt, a virtio console device cannot be assigned a port number greater than zero on a vioserial bus. This leads to port collision errors when adding more than 1 virtio console device on a single vioserial bus. After applying this patch, one can add multiple console ports under a single vioserial bus. Here is a link to CI results for this series: https://gitlab.com/aaronbmalik/libvirt/-/pipelines/1831901334 Aaron M. Brown (2): Fix virtio console port assignment on vioserial bus Updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity src/conf/domain_addr.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) -- 2.39.5 (Apple Git-154)

1 2

[PATCH 0/7] nss: Couple of fixes and small improvements
by Michal Privoznik 22 May '25

22 May '25

I've noticed most of these after I've turned on debugging for the NSS plugin: diff --git i/tools/nss/libvirt_nss.h w/tools/nss/libvirt_nss.h index 54a0216013..f9c3136985 100644 --- i/tools/nss/libvirt_nss.h +++ w/tools/nss/libvirt_nss.h @@ -35 +35 @@ -#if 0 +#if 1 Michal Prívozník (7): libvirt_nss_macs: Fix type of @len in findMACsFromJSON() nss: Add missing includes for gai_strerror() nss: Declare g_autofree and g_steal_pointer() macros libvirt_nss: Use automatic memory freeing libvirt_nss: Drop needless cleanup labels libvirt_nss: Allocate buffer in ERROR() dynamically libvirt_nss: Allocate buffer in aiforaf() dynamically build-aux/syntax-check.mk | 2 +- tools/nss/libvirt_nss.c | 52 +++++++++++++--------------------- tools/nss/libvirt_nss.h | 33 +++++++++++++++++++-- tools/nss/libvirt_nss_leases.c | 3 ++ tools/nss/libvirt_nss_macs.c | 2 +- 5 files changed, 55 insertions(+), 37 deletions(-) -- 2.49.0

6 16

[PATCH] virsh: Do not print warnings with "error:" prefix
by Jiri Denemark 22 May '25

22 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> Both vshWarn and vshError are just wrappers around vshPrintStderr which properly propagates the message level to the log, but fails to honor it when printing on stderr. https://issues.redhat.com/browse/RHEL-79460 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- tools/vsh.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/vsh.c b/tools/vsh.c index 05845e2c1e..e892cbca22 100644 --- a/tools/vsh.c +++ b/tools/vsh.c @@ -2123,7 +2123,11 @@ vshPrintStderr(vshControl *ctl, * printing to stderr will not interleave correctly with stdout * unless we flush between every transition between streams. */ fflush(stdout); - fprintf(stderr, _("error: %1$s\n"), NULLSTR(str)); + + if (level == VSH_ERR_WARNING) + fprintf(stderr, _("warning: %1$s\n"), NULLSTR(str)); + else + fprintf(stderr, _("error: %1$s\n"), NULLSTR(str)); fflush(stderr); } -- 2.49.0

2 1

[PATCH v5 0/5] Adding POWER11 CPU Support
by Narayana Murty N 22 May '25

22 May '25

This patch series introduces the necessary changes to support the POWER11 CPU and POWER11 host in libvirt. Additionally, it updates the QEMU capabilities with the latest QEMU version v10.0.0 to include power11 in the capabilities tests.During testing of v2 patches found a bug in qemu which sets wrong default cpu for pre-9.0 machines, that was fixed in qemu v10.0.0. Patch Summary: Patch 0001: tests: Pin pseries-2.7 tests to the version 7.0. Patch 0002: Fix: qemuhotplugtest Set the cpu version at source as POWER9. Patch 0003: Add capabilities test support for QEMU 10.0.0 on PPC64. Patch 0004: Add POWER11 CPU model support. Patch 0005: Add POWER11 host model support. The corresponding patches for the Linux kernel and QEMU are already upstream. Relevant links are provided below: Linux kernel patches: 1. Linux P11 support: commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode") 2. Linux P11 KVM support: commit 96e266e3bcd6 ("KVM: PPC: Book3S HV: Add Power11 capability support for Nested PAPR guests") Qemu patches: 3. Qemu P11 support: commit 273db89bcaf4 ("ppc/pseries: Add Power11 cpu type") 4. Qemu P11 DD02.0 support: commit c0d964076c3e ("target/ppc: Add Power11 DD2.0 processor") 5. Qemu pre-9.0 pseries michines changing default cpu with Qemu commit 1490d0bcdfcb ("ppc/spapr: fix default cpu for pre-9.0 machines."). Note on CPU model naming: From the discussion in the community thread (https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ICUS…) we will continue using the uppercase only for POWER11 for the CPU model name. This is consistent with the naming convention used for existing POWER models (e.g., POWER9, POWER10) in libvirt's CPU map and avoids compatibility issues with existing tooling and test expectations. Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com> ---- Changelog: -V4: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/ICUS… *Continue to use POWER11 in uppercase, following feedback. *Test data caps_10.0.0.ppc64.replies generated with QEMU v10.0.0. -V3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PGSB… *Rebased to top of the tree as I saw some tests were failing with recent commits. -V2:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/JQ5UJFWJG35OFX54RQIDHFUSX3RIYIYP/?sort=thread *Instead of removing pseries-2.7 related tests, they are now pinned to the latest available capabilities version 7.0.0. *patch0003: description explained why the cpu version changed. *change the cpu model name to lower case. *Fixing the hotplugtest by setting the cpu version at source as POWER9 *default CPU change for pseries machines preior to pseries-9.0 tests cases for tcg fixed. * Fixing the compat models check for host CPU names in both lowercase and uppercase. -V1:https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/4A3IND2QP5CE654XE755ICRZKLUNYXAE/ *Addressed v2 patch readability issues. Narayana Murty N (5): tests: Pin pseries-2.7 tests to the version 7.0 tests: qemuhotplugtest: Set the cpu version at source for PPC64 tests tests: Add capabilities for QEMU 10.0.0 on ppc64 cpu_map: Add POWER11 CPU model support cpu_ppc64: Add POWER11 host-model support src/cpu/cpu_ppc64.c | 8 +- src/cpu_map/index.xml | 1 + src/cpu_map/meson.build | 1 + src/cpu_map/ppc64_POWER11.xml | 6 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 191 + .../caps_10.0.0_ppc64.replies | 39513 ++++++++++++++++ .../caps_10.0.0_ppc64.xml | 1088 + .../ppc64-modern-bulk-domain.xml | 3 +- .../ppc64-modern-individual-domain.xml | 3 +- .../disk-floppy-pseries.ppc64-latest.xml | 2 +- .../memory-hotplug-nvdimm-ppc64.xml | 3 +- .../memory-hotplug-ppc64-nonuma.xml | 3 + .../panic-pseries.ppc64-latest.args | 2 +- .../panic-pseries.ppc64-latest.xml | 2 +- ...ault-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} | 0 ...fault-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} | 0 ...ault-cpu-kvm-pseries-3.1.ppc64-latest.args | 2 +- ...fault-cpu-kvm-pseries-3.1.ppc64-latest.xml | 2 +- ...ault-cpu-kvm-pseries-4.2.ppc64-latest.args | 2 +- ...fault-cpu-kvm-pseries-4.2.ppc64-latest.xml | 2 +- ...ault-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} | 0 ...fault-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} | 0 ...efault-models.ppc64-latest.abi-update.args | 4 +- ...default-models.ppc64-latest.abi-update.xml | 2 +- ...4-pseries-default-models.ppc64-latest.args | 4 +- ...64-pseries-default-models.ppc64-latest.xml | 2 +- .../ppc64-pseries-graphics.ppc64-latest.args | 4 +- .../ppc64-pseries-graphics.ppc64-latest.xml | 2 +- .../ppc64-pseries-headless.ppc64-latest.args | 4 +- .../ppc64-pseries-headless.ppc64-latest.xml | 2 +- ...eries-minimal.ppc64-latest.abi-update.args | 2 +- ...series-minimal.ppc64-latest.abi-update.xml | 2 +- .../ppc64-pseries-minimal.ppc64-latest.args | 2 +- .../ppc64-pseries-minimal.ppc64-latest.xml | 2 +- .../ppc64-tpmproxy-single.ppc64-latest.args | 2 +- .../ppc64-tpmproxy-single.ppc64-latest.xml | 2 +- .../ppc64-tpmproxy-with-tpm.ppc64-latest.args | 2 +- .../ppc64-tpmproxy-with-tpm.ppc64-latest.xml | 2 +- .../pseries-basic.ppc64-latest.args | 2 +- .../pseries-basic.ppc64-latest.xml | 2 +- .../pseries-console-virtio.ppc64-latest.args | 2 +- .../pseries-console-virtio.ppc64-latest.xml | 2 +- ...eries-cpu-compat-power11.ppc64-latest.args | 31 + ...series-cpu-compat-power11.ppc64-latest.err | 1 + ...series-cpu-compat-power11.ppc64-latest.xml | 29 + .../pseries-cpu-compat-power11.xml | 19 + .../pseries-cpu-le.ppc64-latest.args | 2 +- .../pseries-cpu-le.ppc64-latest.xml | 2 +- .../pseries-features.ppc64-latest.args | 2 +- .../pseries-features.ppc64-latest.xml | 2 +- .../pseries-hostdevs-1.ppc64-latest.args | 2 +- .../pseries-hostdevs-1.ppc64-latest.xml | 2 +- .../pseries-hostdevs-2.ppc64-latest.args | 2 +- .../pseries-hostdevs-2.ppc64-latest.xml | 2 +- .../pseries-hostdevs-3.ppc64-latest.args | 2 +- .../pseries-hostdevs-3.ppc64-latest.xml | 2 +- .../pseries-many-buses-1.ppc64-latest.args | 2 +- .../pseries-many-buses-1.ppc64-latest.xml | 2 +- .../pseries-many-buses-2.ppc64-latest.args | 2 +- .../pseries-many-buses-2.ppc64-latest.xml | 2 +- .../pseries-many-devices.ppc64-latest.args | 2 +- .../pseries-many-devices.ppc64-latest.xml | 2 +- .../pseries-nvram.ppc64-latest.args | 2 +- .../pseries-nvram.ppc64-latest.xml | 2 +- .../pseries-panic-missing.ppc64-latest.args | 2 +- .../pseries-panic-missing.ppc64-latest.xml | 2 +- ...pseries-panic-no-address.ppc64-latest.args | 2 +- .../pseries-panic-no-address.ppc64-latest.xml | 2 +- ...ries-phb-default-missing.ppc64-latest.args | 2 +- ...eries-phb-default-missing.ppc64-latest.xml | 2 +- .../pseries-phb-numa-node.ppc64-latest.args | 2 +- .../pseries-phb-numa-node.ppc64-latest.xml | 2 +- .../pseries-phb-simple.ppc64-latest.args | 6 +- .../pseries-phb-simple.ppc64-latest.xml | 2 +- .../pseries-phb-user-alias.ppc64-latest.args | 6 +- .../pseries-phb-user-alias.ppc64-latest.xml | 2 +- .../pseries-serial-native.ppc64-latest.args | 2 +- .../pseries-serial-native.ppc64-latest.xml | 2 +- .../pseries-serial-pci.ppc64-latest.args | 2 +- .../pseries-serial-pci.ppc64-latest.xml | 2 +- .../pseries-serial-usb.ppc64-latest.args | 2 +- .../pseries-serial-usb.ppc64-latest.xml | 2 +- .../pseries-usb-default.ppc64-latest.args | 2 +- .../pseries-usb-default.ppc64-latest.xml | 2 +- .../pseries-usb-kbd.ppc64-latest.args | 2 +- .../pseries-usb-kbd.ppc64-latest.xml | 2 +- .../pseries-usb-multi.ppc64-latest.args | 2 +- .../pseries-usb-multi.ppc64-latest.xml | 2 +- ...series-vio-user-assigned.ppc64-latest.args | 7 +- ...pseries-vio-user-assigned.ppc64-latest.xml | 2 +- .../pseries-vio.ppc64-latest.args | 7 +- .../pseries-vio.ppc64-latest.xml | 2 +- ...fault-pseries.ppc64-latest.abi-update.args | 2 +- ...efault-pseries.ppc64-latest.abi-update.xml | 2 +- ...ntroller-default-pseries.ppc64-latest.args | 2 +- ...ontroller-default-pseries.ppc64-latest.xml | 2 +- ...fault-unavailable-pseries.ppc64-latest.xml | 2 +- tests/qemuxmlconftest.c | 8 +- tests/testutilshostcpus.h | 11 + tests/testutilsqemu.c | 4 + tests/testutilsqemu.h | 1 + 101 files changed, 41005 insertions(+), 101 deletions(-) create mode 100644 src/cpu_map/ppc64_POWER11.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0.ppc64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_ppc64.xml rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.args} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-kvm-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-kvm-pseries-2.7.ppc64-7.0.0.xml} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.args => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.args} (100%) rename tests/qemuxmlconfdata/{ppc64-default-cpu-tcg-pseries-2.7.ppc64-latest.xml => ppc64-default-cpu-tcg-pseries-2.7.ppc64-7.0.0.xml} (100%) create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.args create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.err create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.ppc64-latest.xml create mode 100644 tests/qemuxmlconfdata/pseries-cpu-compat-power11.xml -- 2.48.1

3 8

[PATCH] docs: domain: Explain supported options of 'error_policy'
by Peter Krempa 22 May '25

22 May '25

From: Peter Krempa <pkrempa(a)redhat.com> Explain what the individual settings actually result in. The changes are based on the paraprhase of qemu documentation which in 'qemu-options.hx' states: ``werror=action,rerror=action`` Specify which action to take on write and read errors. Valid actions are: "ignore" (ignore the error and try to continue), "stop" (pause QEMU), "report" (report the error to the guest), "enospc" (pause QEMU only if the host disk is full; report the error to the guest otherwise). The default setting is ``werror=enospc`` and ``rerror=report``. Closes: https://gitlab.com/libvirt/libvirt/-/issues/138 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index c7c75ae219..a23a746229 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -3451,8 +3451,12 @@ paravirtualized driver is specified via the ``disk`` element. and sync requests from guest are ignored). :since:`Since 0.6.0` - The optional ``error_policy`` attribute controls how the hypervisor will - behave on a disk read or write error, possible values are "stop", - "report" (:since:`since 0.9.7`), "ignore", and "enospace". + behave on a disk read or write error, possible values are ``stop`` ( + suspend/pause the domain on error), ``report`` (report the error to the + guest OS; :since:`since 0.9.7`), ``ignore`` (ignore the error and try to + continue), and ``enospace`` (suspend/pause the domain only if host storage + is full; report the error to the guest OS otherwise). + The default is left to the discretion of the hypervisor. :since:`Since 0.8.0`. - The optional ``rerror_policy`` attribute controls behavior for read -- 2.49.0

2 1

[PATCH v2 0/3] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 22 May '25

22 May '25

Changelog v2 - changed behavior from disabling features on the host model to instead flagging the guest CPU to disable deprecated features - removed disabling deprecated features on host model in virQEMUCapsInitCPUModelS390 - added flagging deprecated_feats in qemuProcessUpdateGuestCPU - added tests for deprecated_features='on' - split virQEMUCapsUpdateCPUDeprecatedFeatures update and qemuProcessUpdateGuestCPU changes The intention of reporting deprecated features and modifying the guest CPU model was to alleviate the user from the burden of preparing a guest with the necessary amendments to assure migration to newer hardware. While that goal was met by way of the "deprecated_features='on|off'" attribute, it still adds an extra step that the user must be aware to prepare a guest for migration and the errors that stem from an unsuccessful migration (due to feature incompatibility) is not always clear how to resolve. These patches make s390 CPU host models migration ready from the get-go by disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. Collin Walling (3): qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: process: refactor deprecated features code qemu: process: disable deprecated features for s390 models by default src/qemu/qemu_capabilities.c | 6 ++-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_process.c | 30 ++++++++++++----- ...l-deprecated-features-on.s390x-latest.args | 32 +++++++++++++++++++ ...el-deprecated-features-on.s390x-latest.xml | 25 +++++++++++++++ .../cpu-model-deprecated-features-on.xml | 15 +++++++++ ...default-video-type-s390x.s390x-latest.args | 2 +- ...vfio-zpci-ccw-memballoon.s390x-latest.args | 2 +- .../launch-security-s390-pv.s390x-latest.args | 2 +- ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 2 +- .../s390-defaultconsole.s390x-latest.args | 2 +- .../s390-panic.s390x-latest.args | 2 +- tests/qemuxmlconftest.c | 1 + 14 files changed, 108 insertions(+), 19 deletions(-) create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-on.xml -- 2.47.1

1 5

RFC: schemas: resolving path type inconsistency in XML schemas
by Kirill Shchetiniuk 21 May '25

21 May '25

Hello everyone, Sometime ago I sent a patch changing the XML schema to add GTK support for libvirt. As the type for one path argument, I used the <text/> type, simply copying the similar approach from another place in the XML schema definition. I was told that it's not the best way to use the <text/> type for paths and that absFilePath, a defined basic type for paths, should be used instead. After this, I decided to fix this in a place where I had seen the same approach, too. After further investigation, I found a lot more places where the <text/> type is used for paths. Moreover, I found out that we have at least 4 type definitions for paths (files and directories). Some of these types accept simply everything, others paths starting with "/" or even Windows-style disk names. <define name="filePath"> <data type="string"> <param name="pattern">.+</param> </data> </define> <define name="dirPath"> <data type="string"> <param name="pattern">.+</param> </data> </define> <define name="absFilePath"> <data type="string"> <param name="pattern">(/|[a-zA-Z]:\\).+</param> </data> </define> <define name="absDirPath"> <data type="string"> <param name="pattern">/.*</param> </data> </define> According to this, I have the following questions: 1. Do we allow users to use relative paths, or MUST all paths be absolute? 2. Do we have to accept Windows-style paths everywhere? 3. Do we need to have different types for directories? For example, in some places, the filePath type is used for directory parameters. And as a last question, do we want to unify the basic types related to paths to maintain the schemas more consistent? Kirill

2 1

[PATCH 0/2] qemu: monitor: Fix handling of 'detach' for 'migrate' and 'dump-guest-memory' QMP commands
by Peter Krempa 21 May '25

21 May '25

QEMU is deprecating 'detach' argument of 'migrate' as it was never actually used. Drop it in libvirt as we always specify it. The monitor handler of 'dump-guest-memory' allows controlling 'detach' but always passes true. Libvirt doesn't want to block the monitor so hardcode 'true' in the monitor code instead. Peter Krempa (2): qemuMonitorDumpToFd: Drop 'detach' argument qemuMonitorJSONMigrate: Drop 'detach' QMP option src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor.c | 5 ++--- src/qemu/qemu_monitor.h | 3 +-- src/qemu/qemu_monitor_json.c | 6 ++---- src/qemu/qemu_monitor_json.h | 3 +-- tests/qemumonitorjsontest.c | 3 +-- 6 files changed, 8 insertions(+), 14 deletions(-) -- 2.49.0

2 3

[PATCH] build-aux: simplify grep detection on FreeBSD
by Roman Bogorodskiy 21 May '25

21 May '25

From: Alexey Dokuchaev <danfe(a)FreeBSD.org> For quite some time now FreeBSD provides its own version of the grep(1) tool, and the GNU grep from the ports collection is available as ggrep(1). So remove the detection code and just request ggrep. Signed-off-by: Alexey Dokuchaev <danfe(a)FreeBSD.org> --- build-aux/meson.build | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/build-aux/meson.build b/build-aux/meson.build index bcd10e89f2..56c91971cf 100644 --- a/build-aux/meson.build +++ b/build-aux/meson.build @@ -13,23 +13,10 @@ if git and tests_enabled[0] if host_machine.system() == 'freebsd' or host_machine.system() == 'darwin' make_prog = find_program('gmake') sed_prog = find_program('gsed') + grep_prog = find_program('ggrep') else make_prog = find_program('make') sed_prog = find_program('sed') - endif - - if host_machine.system() == 'freebsd' - grep_prog = find_program('grep') - grep_cmd = run_command(grep_prog, '--version', check: true) - if grep_cmd.stdout().startswith('grep (BSD grep') - grep_prog = find_program('/usr/local/bin/grep', required: false) - if not grep_prog.found() - error('GNU grep not found') - endif - endif - elif host_machine.system() == 'darwin' - grep_prog = find_program('ggrep') - else grep_prog = find_program('grep') endif -- 2.49.0

2 1