May 2025 - Devel - libvirt List Archives

[PATCH v3 0/2] tests: Add capabilities for QEMU 10.0.0 on aarch64
by Andrea Bolognani 12 May '25

12 May '25

This combines my [v1] with Mattew's [v2] in a way that preserves accurate authorship information, correctly splits changes across patches and adequately documents the changes themselves. [v1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4NQ… [v2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LWEY… Andrea Bolognani (1): tests: Use collie instead of borzoi for aarch64 tests Matthew R. Ochs (1): tests: Add capabilities for QEMU 10.0.0 on aarch64 .../qemu_10.0.0-virt.aarch64.xml | 237 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 237 + .../caps_10.0.0_aarch64.replies | 37426 ++++++++++++++++ .../caps_10.0.0_aarch64.xml | 546 + ...arch64-cpu-passthrough.aarch64-latest.args | 5 +- .../aarch64-kvm-32-on-64.aarch64-latest.args | 5 +- .../aarch64-noacpi-acpi.aarch64-latest.err | 2 +- tests/qemuxmlconfdata/aarch64-noacpi-acpi.xml | 2 +- ...usb-minimal.aarch64-latest.abi-update.args | 3 +- ...ousb-minimal.aarch64-latest.abi-update.xml | 2 +- .../aarch64-nousb-minimal.aarch64-latest.args | 3 +- .../aarch64-nousb-minimal.aarch64-latest.xml | 2 +- .../qemuxmlconfdata/aarch64-nousb-minimal.xml | 2 +- .../aarch64-virt-graphics.aarch64-latest.args | 5 +- ...h64-virt-headless-mmio.aarch64-latest.args | 5 +- .../aarch64-virt-headless.aarch64-latest.args | 5 +- .../aarch64-virt-virtio.aarch64-latest.args | 5 +- ...o-pci-manual-addresses.aarch64-latest.args | 5 +- .../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 | 6 +- .../arm-vexpressa9-virtio.aarch64-latest.xml | 3 - .../disk-arm-virtio-sd.aarch64-latest.args | 1 - .../disk-arm-virtio-sd.aarch64-latest.xml | 3 - ...mware-auto-efi-aarch64.aarch64-latest.args | 5 +- ...-loader-raw.aarch64-latest.abi-update.args | 5 +- ...-efi-format-loader-raw.aarch64-latest.args | 5 +- ...i-aarch64-legacy-paths.aarch64-latest.args | 5 +- ...anual-efi-acpi-aarch64.aarch64-latest.args | 5 +- ...ual-efi-noacpi-aarch64.aarch64-latest.args | 5 +- .../pvpanic-pci-aarch64.aarch64-latest.args | 5 +- ...pci-no-address-aarch64.aarch64-latest.args | 5 +- ...default-fallback-nousb.aarch64-latest.args | 3 +- ...-default-fallback-nousb.aarch64-latest.xml | 2 +- ...ntroller-default-nousb.aarch64-latest.args | 3 +- ...ontroller-default-nousb.aarch64-latest.xml | 2 +- .../usb-controller-default-nousb.xml | 2 +- ...ault-unavailable-nousb.aarch64-latest.args | 3 +- ...fault-unavailable-nousb.aarch64-latest.xml | 2 +- .../virtio-iommu-aarch64.aarch64-latest.args | 5 +- tests/qemuxmlconftest.c | 2 +- 43 files changed, 38500 insertions(+), 82 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.0.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_aarch64.xml -- 2.49.0

2 5

[PATCH 0/2] Fix bug in qemuDomainPrepareHostdevPCI and reword errors
by Peter Krempa 12 May '25

12 May '25

Peter Krempa (2): qemuDomainPrepareHostdevPCI: Fix return values after conversion from bool to int qemuDomainPrepareHostdevPCI: Simplify error messages src/qemu/qemu_domain.c | 43 +++++++++++++++++------------------------- 1 file changed, 17 insertions(+), 26 deletions(-) -- 2.49.0

2 3

[PATCHv2 0/5] qemu: Introduce nvme disk emulation support
by honglei.wang＠smartx.com 12 May '25

12 May '25

From: hongleiwang <honglei.wang(a)smartx.com> QEMU has supported nvme disk emulation for a long time, see: https://qemu-project.gitlab.io/qemu/system/devices/nvme.html. The following patches introduce nvme-ns disk bus type: A disk with nvme-ns as bus is represented as an nvme namespace and needs to be attached to an nvme controller. In XML, it can be used like this: <devices> ... <disk type='file' device='disk'> <driver name='qemu' type='raw'/> <source file='/tmp/data.img'/> <target dev='nvmensa' bus='nvme-ns'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <controller type='nvme' index='0'> <serial>nvme-controller-serial-value</serial> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> ... </devices> Signed-off-by: ray <honglei.wang(a)smartx.com> --- Compared to patch v1, this version removes the nvme bus type implementation and keeps only the nvme controller + nvme-ns bus approach. ray (5): qemu: Add support for NVMe namespace disk bus type qemu_capabilities: Add support for nvme-ns bus capabilities schema: Add nvme controller and nvme-ns bus defination tests: Add test case for nvme-ns device configuration NEWS: Document qemu nvme disk emulation feature NEWS.rst | 17 +++++++++ src/conf/domain_conf.c | 39 ++++++++++++++++++++ src/conf/domain_conf.h | 7 ++++ src/conf/domain_postparse.c | 2 ++ src/conf/domain_validate.c | 4 ++- src/conf/schemas/domaincommon.rng | 11 +++++- src/conf/virconftypes.h | 2 ++ src/hyperv/hyperv_driver.c | 2 ++ src/qemu/qemu_alias.c | 1 + src/qemu/qemu_capabilities.c | 5 +++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 26 ++++++++++++++ src/qemu/qemu_domain_address.c | 5 +++ src/qemu/qemu_hotplug.c | 14 ++++++-- src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 18 ++++++++++ src/test/test_driver.c | 2 ++ src/util/virutil.c | 2 +- src/vbox/vbox_common.c | 2 ++ src/vmx/vmx.c | 1 + .../qemu_10.0.0-q35.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_4.2.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_4.2.0.ppc64.xml | 1 + .../domaincapsdata/qemu_5.0.0-tcg-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_5.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.0.0-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_5.1.0.sparc.xml | 1 + tests/domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml | 1 + tests/domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0-tcg.x86_64+hvf.xml | 1 + tests/domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_7.2.0.ppc.xml | 1 + tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.2.0-virt.aarch64.xml | 1 + .../domaincapsdata/qemu_8.2.0-virt.loongarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 1 + tests/domaincapsdata/qemu_8.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.1.0-virt.riscv64.xml | 1 + tests/domaincapsdata/qemu_9.1.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.2.0-hvf.aarch64+hvf.xml | 1 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_6.2.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_7.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_7.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 + .../qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_8.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 1 + .../caps_8.2.0_loongarch64.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 1 + .../disk-nvme-ns-device.x86_64-latest.args | 36 +++++++++++++++++++ .../disk-nvme-ns-device.x86_64-latest.xml | 42 ++++++++++++++++++++++ tests/qemuxmlconfdata/disk-nvme-ns-device.xml | 41 +++++++++++++++++++++ tests/qemuxmlconftest.c | 1 + 117 files changed, 370 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxmlconfdata/disk-nvme-ns-device.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/disk-nvme-ns-device.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/disk-nvme-ns-device.xml -- 2.11.0

4 22

[PATCH] qemu: fix qemuMigrationCapability enum
by Dmitry Frolov 12 May '25

12 May '25

Enum variable of type qemuMigrationCapability is checked for zero in src/qemu/qemu_migration_params.c:729. "if (item->optional) { ..." Actualy, QEMU_MIGRATION_CAP_XBZRLE enum constant has value 0. Thus, all uninitialized .optinnal fields of the static array qemuMigrationParamsFlagMap[] will be implicitly initialized with value 0 (QEMU_MIGRATION_CAP_XBZRLE). To my opinion, introducing a separate enum for optional capabilities, would be a better solution. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Frolov <frolov(a)swemel.ru> --- src/qemu/qemu_migration_params.c | 16 +++++++++++----- src/qemu/qemu_migration_params.h | 12 ++++++++++-- 2 files changed, 21 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_migration_params.c b/src/qemu/qemu_migration_params.c index c10660d6f2..23c463dbbb 100644 --- a/src/qemu/qemu_migration_params.c +++ b/src/qemu/qemu_migration_params.c @@ -104,6 +104,11 @@ VIR_ENUM_IMPL(qemuMigrationCapability, "dirty-bitmaps", "return-path", "zero-copy-send", +); + +VIR_ENUM_IMPL(qemuMigrationOptCap, + QEMU_MIGRATION_OPTCAP_LAST, + "none", "postcopy-preempt", "switchover-ack", ); @@ -152,7 +157,7 @@ struct _qemuMigrationParamsFlagMapItem { /* An optional capability to set in addition to @cap in case it is * supported. Depending on @part either one or both sides of migration * has to support the optional capability to be enabled. */ - qemuMigrationCapability optional; + qemuMigrationOptCap optional; /* Bit-wise OR of qemuMigrationParty. Determines whether the capability has * to be enabled on the source, on the destination, or on both sides of * migration. */ @@ -200,7 +205,7 @@ static const qemuMigrationParamsFlagMapItem qemuMigrationParamsFlagMap[] = { {.match = QEMU_MIGRATION_FLAG_REQUIRED, .flag = VIR_MIGRATE_POSTCOPY, .cap = QEMU_MIGRATION_CAP_POSTCOPY, - .optional = QEMU_MIGRATION_CAP_POSTCOPY_PREEMPT, + .optional = QEMU_MIGRATION_OPTCAP_POSTCOPY_PREEMPT, .party = QEMU_MIGRATION_SOURCE | QEMU_MIGRATION_DESTINATION}, {.match = QEMU_MIGRATION_FLAG_REQUIRED, @@ -211,7 +216,7 @@ static const qemuMigrationParamsFlagMapItem qemuMigrationParamsFlagMap[] = { {.match = QEMU_MIGRATION_FLAG_FORBIDDEN, .flag = VIR_MIGRATE_TUNNELLED, .cap = QEMU_MIGRATION_CAP_RETURN_PATH, - .optional = QEMU_MIGRATION_CAP_SWITCHOVER_ACK, + .optional = QEMU_MIGRATION_OPTCAP_SWITCHOVER_ACK, .party = QEMU_MIGRATION_SOURCE | QEMU_MIGRATION_DESTINATION}, {.match = QEMU_MIGRATION_FLAG_REQUIRED, @@ -725,8 +730,9 @@ qemuMigrationParamsFromFlags(virTypedParameterPtr params, qemuMigrationCapabilityTypeToString(item->cap)); ignore_value(virBitmapSetBit(migParams->caps, item->cap)); - if (item->optional) { - qemuMigrationCapability opt = item->optional; + if (item->optional > QEMU_MIGRATION_OPTCAP_NONE && + item->optional < QEMU_MIGRATION_OPTCAP_LAST) { + qemuMigrationOptCap opt = item->optional; ignore_value(virBitmapSetBit(migParams->optional, opt)); if (item->party != party) ignore_value(virBitmapSetBit(migParams->remoteOptional, opt)); diff --git a/src/qemu/qemu_migration_params.h b/src/qemu/qemu_migration_params.h index 17fc63f527..3246b8487e 100644 --- a/src/qemu/qemu_migration_params.h +++ b/src/qemu/qemu_migration_params.h @@ -40,13 +40,21 @@ typedef enum { QEMU_MIGRATION_CAP_BLOCK_DIRTY_BITMAPS, QEMU_MIGRATION_CAP_RETURN_PATH, QEMU_MIGRATION_CAP_ZERO_COPY_SEND, - QEMU_MIGRATION_CAP_POSTCOPY_PREEMPT, - QEMU_MIGRATION_CAP_SWITCHOVER_ACK, QEMU_MIGRATION_CAP_LAST } qemuMigrationCapability; VIR_ENUM_DECL(qemuMigrationCapability); +typedef enum { + QEMU_MIGRATION_OPTCAP_NONE, + QEMU_MIGRATION_OPTCAP_POSTCOPY_PREEMPT, + QEMU_MIGRATION_OPTCAP_SWITCHOVER_ACK, + + QEMU_MIGRATION_OPTCAP_LAST +} qemuMigrationOptCap; +VIR_ENUM_DECL(qemuMigrationOptCap); + + typedef enum { QEMU_MIGRATION_PARAM_COMPRESS_LEVEL, QEMU_MIGRATION_PARAM_COMPRESS_THREADS, -- 2.34.1

3 5

[PATCH v2 0/5] docs: automated info about machine deprecation/removal info
by Daniel P. Berrangé 11 May '25

11 May '25

Since we deprecate and remove versioned machine types on a fixed schedule, we can automatically ensure that the docs reflect the latest version info, rather than requiring manual updates on each dev cycle. The first patch in this series removes the hack which postponed automatic removal of versioned machine types to the 10.1.0 release, since we're now in the 10.1.0 dev cycle. The second patch in this series fixes the logic to ensure dev snapshots and release candidates don't have an off-by-1 error in setting deprecation and removal thresholds - they must predict the next formal release version number. The following three patches deal with the docs stuff. With this series applied all versioned machine types prior to 4.1 are now removed (hidden). We can delete the code at our leisure. Changed in v2: - Remove hack that temporarily postponed automatic deletion of machine types - Fix docs version info for stable bugfix releases Daniel P. Berrangé (5): Revert "include/hw: temporarily disable deletion of versioned machine types" include/hw/boards: cope with dev/rc versions in deprecation checks docs/about/deprecated: auto-generate a note for versioned machine types docs/about/removed-features: auto-generate a note for versioned machine types include/hw/boards: add warning about changing deprecation logic docs/about/deprecated.rst | 7 ++++ docs/about/removed-features.rst | 10 +++--- docs/conf.py | 39 +++++++++++++++++++++- include/hw/boards.h | 58 +++++++++++++++++++++------------ 4 files changed, 89 insertions(+), 25 deletions(-) -- 2.49.0

4 12

[PATCH v3 0/5] docs: automated info about machine deprecation/removal info
by Daniel P. Berrangé 11 May '25

11 May '25

Since we deprecate and remove versioned machine types on a fixed schedule, we can automatically ensure that the docs reflect the latest version info, rather than requiring manual updates on each dev cycle. The first patch in this series removes the hack which postponed automatic removal of versioned machine types to the 10.1.0 release, since we're now in the 10.1.0 dev cycle. The second patch in this series fixes the logic to ensure dev snapshots and release candidates don't have an off-by-1 error in setting deprecation and removal thresholds - they must predict the next formal release version number. The following three patches deal with the docs stuff. Changed in v3: - Remove mistaken mention of 'ppc', only 'ppc64' has versioned machine types Changed in v2: - Remove hack that temporarily postponed automatic deletion of machine types - Fix docs version info for stable bugfix releases Daniel P. Berrangé (5): Revert "include/hw: temporarily disable deletion of versioned machine types" include/hw/boards: cope with dev/rc versions in deprecation checks docs/about/deprecated: auto-generate a note for versioned machine types docs/about/removed-features: auto-generate a note for versioned machine types include/hw/boards: add warning about changing deprecation logic docs/about/deprecated.rst | 7 ++++ docs/about/removed-features.rst | 10 +++--- docs/conf.py | 39 +++++++++++++++++++++- include/hw/boards.h | 58 +++++++++++++++++++++------------ 4 files changed, 89 insertions(+), 25 deletions(-) -- 2.49.0

4 14

[PULL 0/6] Versioned machine type deprecation policy patches
by Daniel P. Berrangé 10 May '25

10 May '25

The following changes since commit 57b6f8d07f1478375f85a4593a207e936c63ff59: Merge tag 'pull-target-arm-20250506' of https://git.linaro.org/people/pmaydell/qemu-arm into staging (2025-05-07 14:28:20 -0400) are available in the Git repository at: https://gitlab.com/berrange/qemu tags/docs-dep-pull-request for you to fetch changes up to 3fbb0a1397a9acea523f3c8062df8c6f8032788d: include/hw/boards: add warning about changing deprecation logic (2025-05-08 17:11:16 +0100) ---------------------------------------------------------------- * Remove test relying on 4.1 machine type that is about to be disabled * Fix off-by-1 in deprecation/removal logic for versioned machine types to cope with dev/rc versions * Enable logic for disabling registration of versioned machine types which have exceeded the deprecation lifetime policy. * Add automated version information to documentation about which versioned machine types are deprecated and removed ---------------------------------------------------------------- Daniel P. Berrangé (5): Revert "include/hw: temporarily disable deletion of versioned machine types" include/hw/boards: cope with dev/rc versions in deprecation checks docs/about/deprecated: auto-generate a note for versioned machine types docs/about/removed-features: auto-generate a note for versioned machine types include/hw/boards: add warning about changing deprecation logic Thomas Huth (1): tests/qtest/q35-test: Remove the obsolete test_without_smram_base test docs/about/deprecated.rst | 7 ++++ docs/about/removed-features.rst | 10 +++--- docs/conf.py | 39 +++++++++++++++++++++- include/hw/boards.h | 58 +++++++++++++++++++++------------ tests/qtest/q35-test.c | 37 +-------------------- 5 files changed, 90 insertions(+), 61 deletions(-) -- 2.49.0

2 7

RFC: libvirt-tck bhyve/FreeBSD support
by Roman Bogorodskiy 09 May '25

09 May '25

Hi, I'd like to test the bhyve driver using libvirt-tck, which seems to be very useful both from the continuous integration perspective, and making the bhyve driver closer to other drivers to improve integration with other tooling. As a small proof-of-concept I made just a single test 060-persistent-lifecycle.t work with bhyve, though it was enough to highlight a bunch of issues. I've created a pull request on Gitlab: https://gitlab.com/libvirt/libvirt-tck/-/merge_requests/58 but apparently it's not very active there, so I'll briefly repeat it here as well. Issues I encountered: * Network Filters not supported It could be solved by implementing the network filters (obviously), but realistically it's probably not going to happen soon. I guess there are at least 3 options to solve that: - Add a test suite config knob to skip nwfilters - Don't fail the test suite on non-implemented list_nwfilters - In the bhyve driver, add a minimal implementation which always returns 0 rules * Hardcoded /dev/urandom RNG devices As the bhyve driver now supports virtio-rnd with /dev/random backend, should there be a configuration knob for libvirt-tck to override the RNG device definition? * Missing IDE device support Bhyve does not (and likely never will) support IDE devices, but supports SATA devices. Similar to the previous item, should there be a config knob? Or maybe just change default to sata? * Missing pty console support Bhyve does not support pty consoles. The bhyve driver currently supports the nmdm console, and bhyve also supports virtio-console and TCP socket connection which are not yet supported by the driver. * Firmware loader specification This is probably one of the trickiest ones. When no loader specified, the bhyve driver uses the bhyveload(8) loader which allows to boot FreeBSD guests only. That means that any other guest OS requires specifying the BHYVE_UEFI.fd firmware (or use grub-bhyve). I see two options for that: - A test suite/framework configuration knob (again) - Change the bhyve driver to default to BHYVE_UEFI.fd. I like this option for two reasons: it makes bhyve domain XMLs more compatible with other drivers, and also looks like a more reasonable default, because for example I don't run FreeBSD guests inside bhyve very often, so for most of my domains I have to set loader. It's a bit inconvenient that the firmware is not a part of bhyve and needs to be installed through the port, but we can make it possible to set the default firmware via the build option and allow to override that via the bhyve driver configuration, which should provide enough flexibility to users, I guess. Any thoughts and recommendations how to tackle this project appreciated. Thanks, Roman

2 7

[PATCH] rpm: disable zfs on Fedora >= 43
by Daniel P. Berrangé 09 May '25

09 May '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The zfs-fuse package has been dead upstream for a long time and is now retired in Fedora rawhide. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- libvirt.spec.in | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 9217820137..e12bec18d5 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -85,8 +85,8 @@ %endif %endif -# Fedora has zfs-fuse -%if 0%{?fedora} +# Fedora had zfs-fuse until F43 +%if 0%{?fedora} && 0%{?fedora} < 43 %define with_storage_zfs 0%{!?_without_storage_zfs:1} %else %define with_storage_zfs 0 @@ -700,6 +700,9 @@ 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 -- 2.49.0

2 1

[PATCH 0/2] tests: Add capabilities for QEMU 10.0 on aarch64
by Matthew R. Ochs 08 May '25

08 May '25

This is a refresh of a series that Andrea Bolognani posted in February 2025 [1] and provides aarch64 capability support for QEMU v10.0.0. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4NQ… Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com> Matthew R. Ochs (2): tests: Use collie instead of borzoi for aarch64 tests tests: Add capabilities for QEMU 10.0.0 on aarch64 .../qemu_10.0.0-virt.aarch64.xml | 237 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 237 + .../caps_10.0.0_aarch64.replies | 37426 ++++++++++++++++ .../caps_10.0.0_aarch64.xml | 546 + ...arch64-cpu-passthrough.aarch64-latest.args | 5 +- .../aarch64-kvm-32-on-64.aarch64-latest.args | 5 +- .../aarch64-noacpi-acpi.aarch64-latest.err | 2 +- tests/qemuxmlconfdata/aarch64-noacpi-acpi.xml | 2 +- ...usb-minimal.aarch64-latest.abi-update.args | 3 +- ...ousb-minimal.aarch64-latest.abi-update.xml | 2 +- .../aarch64-nousb-minimal.aarch64-latest.args | 3 +- .../aarch64-nousb-minimal.aarch64-latest.xml | 2 +- .../qemuxmlconfdata/aarch64-nousb-minimal.xml | 2 +- .../aarch64-virt-graphics.aarch64-latest.args | 5 +- ...h64-virt-headless-mmio.aarch64-latest.args | 5 +- .../aarch64-virt-headless.aarch64-latest.args | 5 +- .../aarch64-virt-virtio.aarch64-latest.args | 5 +- ...o-pci-manual-addresses.aarch64-latest.args | 5 +- .../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 | 6 +- .../arm-vexpressa9-virtio.aarch64-latest.xml | 3 - .../disk-arm-virtio-sd.aarch64-latest.args | 1 - .../disk-arm-virtio-sd.aarch64-latest.xml | 3 - ...mware-auto-efi-aarch64.aarch64-latest.args | 5 +- ...-loader-raw.aarch64-latest.abi-update.args | 5 +- ...-efi-format-loader-raw.aarch64-latest.args | 5 +- ...i-aarch64-legacy-paths.aarch64-latest.args | 5 +- ...anual-efi-acpi-aarch64.aarch64-latest.args | 5 +- ...ual-efi-noacpi-aarch64.aarch64-latest.args | 5 +- .../pvpanic-pci-aarch64.aarch64-latest.args | 5 +- ...pci-no-address-aarch64.aarch64-latest.args | 5 +- ...default-fallback-nousb.aarch64-latest.args | 3 +- ...-default-fallback-nousb.aarch64-latest.xml | 2 +- ...ntroller-default-nousb.aarch64-latest.args | 3 +- ...ontroller-default-nousb.aarch64-latest.xml | 2 +- .../usb-controller-default-nousb.xml | 2 +- ...ault-unavailable-nousb.aarch64-latest.args | 3 +- ...fault-unavailable-nousb.aarch64-latest.xml | 2 +- .../virtio-iommu-aarch64.aarch64-latest.args | 5 +- tests/qemuxmlconftest.c | 2 +- 43 files changed, 38500 insertions(+), 82 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.0.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_10.0.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.0.0_aarch64.xml -- 2.46.0

4 11