May 2025 - Devel - libvirt List Archives

[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

[PATCH 1/2] NEWS: bhyve: document NVRAM support
by Roman Bogorodskiy 21 May '25

21 May '25

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index e924c08fbf..102e49373a 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -23,6 +23,14 @@ v11.4.0 (unreleased) That option suppresses registration of pkttyagent with polkitd. + * bhyve: support NVRAM configuration for UEFI firmwares + + The bhyve driver now supports specifying NVRAM store file, such as :: + + <os firmware='efi'> + <nvram/> + </os> + * **Bug fixes** * qemu: Fix failure when reverting to internal snapshots -- 2.49.0

2 3

[PATCH 0/5] bhyve: introduce NVRAM support
by Roman Bogorodskiy 21 May '25

21 May '25

Roman Bogorodskiy (5): bhyve: conf: introduce nvramDir bhyve: generate NVRAM bhyve arguments bhyve: firmware: try to guess NVRAM settings bhyve: introduce bhyveDomainDefValidate() bhyve: support removing NVRAM on domain undefine src/bhyve/bhyve_command.c | 8 +- src/bhyve/bhyve_conf.c | 4 + src/bhyve/bhyve_domain.c | 43 ++++++ src/bhyve/bhyve_driver.c | 32 ++++- src/bhyve/bhyve_firmware.c | 119 ++++++++++++++-- src/bhyve/bhyve_process.c | 132 ++++++++++++++++++ src/bhyve/bhyve_process.h | 8 ++ src/bhyve/bhyve_utils.h | 2 + src/bhyve/meson.build | 5 + ...gv-uefi-nvram-template-and-source-set.args | 12 ++ ...-uefi-nvram-template-and-source-set.ldargs | 1 + ...rgv-uefi-nvram-template-and-source-set.xml | 24 ++++ ...bhyvexml2argv-uefi-nvram-template-set.args | 12 ++ ...yvexml2argv-uefi-nvram-template-set.ldargs | 1 + .../bhyvexml2argv-uefi-nvram-template-set.xml | 24 ++++ .../bhyvexml2argv-uefi-nvram.args | 12 ++ .../bhyvexml2argv-uefi-nvram.ldargs | 1 + .../bhyvexml2argv-uefi-nvram.xml | 24 ++++ tests/bhyvexml2argvtest.c | 5 + 19 files changed, 452 insertions(+), 17 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-and-source-set.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram-template-set.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-uefi-nvram.xml -- 2.49.0

2 7

[PATCH 0/4] virsh completer cleanups
by Peter Krempa 20 May '25

20 May '25

Make the core completer code common in all virt shells and annotate few arguments with the existing empty and local-file completers. Peter Krempa (4): virsh: completer: Extract common completer methods from virsh to vsh vsh: Apply empty/local completers to global commands virsh: Apply empty completer to arguments where completion doesn't make sense virsh: domain: Annotate rest of arguments taking local existing file tools/meson.build | 2 +- tools/virsh-backup.c | 6 +- tools/virsh-checkpoint.c | 8 +- tools/virsh-completer-domain.c | 70 ++++++------ tools/virsh-completer-host.c | 12 +- tools/virsh-completer-nodedev.c | 10 +- tools/virsh-completer-pool.c | 6 +- tools/virsh-completer-volume.c | 4 +- tools/virsh-completer.h | 19 +--- tools/virsh-domain.c | 112 ++++++++++--------- tools/virsh-host.c | 6 +- tools/virsh-interface.c | 2 +- tools/virsh-network.c | 9 +- tools/virsh-nodedev.c | 2 +- tools/virsh-nwfilter.c | 4 +- tools/virsh-pool.c | 18 +-- tools/virsh-secret.c | 6 +- tools/virsh-snapshot.c | 8 +- tools/virsh-volume.c | 12 +- tools/virsh.c | 2 +- tools/virsh.h | 2 +- tools/{virsh-completer.c => vsh-completer.c} | 34 +++--- tools/vsh-completer.h | 41 +++++++ tools/vsh.c | 6 + 24 files changed, 222 insertions(+), 179 deletions(-) rename tools/{virsh-completer.c => vsh-completer.c} (85%) create mode 100644 tools/vsh-completer.h -- 2.49.0

2 5

[PATCH] cputest: Skip more tests requiring JSON_MODELS if QEMU is disabled
by Jaroslav Suchanek 20 May '25

20 May '25

From: Jaroslav Suchanek <jsuchane(a)redhat.com> Marking more tests with JSON_MODELS_REQUIRED as these tests fail if QEMU is disabled, typically when running tests on FreeBSD or macOS systems. Signed-off-by: Jaroslav Suchanek <jsuchane(a)redhat.com> --- tests/cputest.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/tests/cputest.c b/tests/cputest.c index de313f6102..bb471d2ae7 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -1183,14 +1183,14 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-D510", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-N450", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362", JSON_MODELS_REQUIRED); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362-2", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Atom-P5362-2", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-650", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-2500", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-2540M", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-4670T", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i5-6600", JSON_HOST); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1270P", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1365U", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1270P", JSON_MODELS_REQUIRED); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-1365U", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-2600-xsaveopt", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Core-i7-3520M", JSON_NONE); @@ -1225,7 +1225,7 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Ryzen-9-3900X-12-Core", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-5110", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-6731E", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Bronze-3408U", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1225-v5", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1245-v5", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-E3-1270-v5", JSON_MODELS); @@ -1244,12 +1244,12 @@ mymain(void) DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6130", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6148", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6152", JSON_MODELS); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6530", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Gold-6530", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Platinum-8268", JSON_HOST); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Platinum-9242", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-Silver-4214R", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-W3520", JSON_HOST); - DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-w7-3465X", JSON_MODELS); + DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-w7-3465X", JSON_MODELS_REQUIRED); DO_TEST_CPUID(VIR_ARCH_X86_64, "Xeon-X5460", JSON_NONE); DO_TEST_CPUID(VIR_ARCH_X86_64, "Ice-Lake-Server", JSON_MODELS); DO_TEST_CPUID(VIR_ARCH_X86_64, "Cooperlake", JSON_MODELS); -- 2.49.0

2 1

[libvirt PATCH] qemu: forbid readonly attribute for externally launched virtiofsd
by Ján Tomko 20 May '25

20 May '25

From: Ján Tomko <jtomko(a)redhat.com> In that case, libvirtd cannot set it on the command line because virtiofsd is not launched by libvirt. https://issues.redhat.com/browse/RHEL-87522 Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- src/qemu/qemu_validate.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 87588024ce..013ff14d75 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -4684,6 +4684,11 @@ qemuValidateDomainDeviceDefFS(virDomainFSDef *fs, _("virtiofs does not support wrpolicy")); return -1; } + if (fs->readonly) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("readonly mode cannot be set for extrenally started virtiofsd")); + return -1; + } } if (fs->model != VIR_DOMAIN_FS_MODEL_DEFAULT) { -- 2.49.0

3 2

libvirt TLS certificates letsencrypt
by Jani Heikkinen 20 May '25

20 May '25

Hello! I am part of infrastructure team at BFH and we are building an openstack installation. A couple of months ago I was experimenting with setting up noVNC consoles with encryption. Connecting until the novncproxy service with TLS can be done with no issues, but the connection between libvirt and the proxy turned out to be problematic. We would really love to use letsencrypt certificates which are generated for each server/container, instead of relying on creating own CA and generate certificates. With libvirt, using letsencrypt is impossible, since the code does bunch of checks for properties of the TLS certificates, see: https://github.com/libvirt/libvirt/blob/bf79a021a6437b4f85469a53f650bff62db… Does anybody know, why these checks exist? They de facto prevent using anything else than self-generated certificates for securing vnc console traffic. Is using my own self-created CA somehow more trustworthy than LetsEncrypt root CA? Best, Jani Heikkinen -- Berner Fachhochschule / Bern University of Applied Sciences IT-Services / Team Linux & Infrastructure Services Jani Heikkinen IT Linux Engineer ___________________________________________________________ Dammweg 3, CH-3013 Bern Telefon direkt +41 31 848 68 14 Telefon Servicedesk +41 31 848 48 48 jani.heikkinen(a)bfh.ch

2 1

[PATCH 0/3] qemu: fix validation of 'fd' passing for backup job and improve debugability of passed FDs
by Peter Krempa 20 May '25

20 May '25

Peter Krempa (3): qemuBackupPrepare: Actually allow 'VIR_STORAGE_NET_HOST_TRANS_FD' docs: backup: Hint at proper selinux labelling of the FD-passed NBD socket qemu: fd: Log information about passed file descriptor docs/formatbackup.rst | 4 +++ src/qemu/qemu_backup.c | 4 ++- src/qemu/qemu_fd.c | 62 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+), 1 deletion(-) -- 2.49.0

2 8

[PATCH v1 0/2] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 20 May '25

20 May '25

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 (2): qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: caps: disable deprecated features for s390 models by default src/qemu/qemu_capabilities.c | 10 +++++++--- src/qemu/qemu_capabilities.h | 3 ++- src/qemu/qemu_driver.c | 3 ++- src/qemu/qemu_process.c | 19 ++++++++++++------- tests/domaincapsdata/qemu_10.0.0.s390x.xml | 8 ++++---- tests/domaincapsdata/qemu_9.1.0.s390x.xml | 8 ++++---- tests/domaincapsdata/qemu_9.2.0.s390x.xml | 8 ++++---- ...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 +- 13 files changed, 41 insertions(+), 30 deletions(-) -- 2.47.1

2 5

[libvirt PATCH 0/2] Remove 'inline' keyword from C files
by Ján Tomko 19 May '25

19 May '25

2 3

[PATCH 0/1] virsh: Add option '--no-pkttyagent'
by Jens Schmidt 19 May '25

19 May '25

As discussed in https://gitlab.com/libvirt/libvirt/-/issues/757. I'm not quite sure about using a long-only-option, since that's a first in virsh. But OTOH this option seems too insignificant to also use one of the precious short option characters for it. Please check and let me know what you think. Thanks! Jens Schmidt (1): virsh: Add option '--no-pkttyagent' NEWS.rst | 4 ++++ docs/manpages/virsh.rst | 8 ++++++++ tools/virsh.c | 13 ++++++++++++- tools/vsh.h | 1 + 4 files changed, 25 insertions(+), 1 deletion(-) -- 2.39.5

3 8

[PATCH v3 0/3] Add virt machine support for configuring PCI high memory MMIO size
by Matthew R. Ochs 16 May '25

16 May '25

This patch series adds support for configuring the PCI high memory MMIO window size for aarch64 virt machine types using the highmem-mmio-size feature introduced in QEMU v10.0.0 [1]. It allows users to configure the size of the high memory MMIO window above 4GB, which can be required to support PCI passthrough with devices that have a large BARs. The feature is exposed through the existing pcihole64 element associated with the PCIe root controller: <controller type='pci' index='0' model='pcie-root'> <pcihole64 unit='GiB'>512</pcihole64> </controller> This existing schema supports the same semantics for the QEMU PC machine pci-hole64-size parameter and is a natural fit for supporting the highmem-mmio-size feature on the aarch64 virt machine. This series is applied over master and depends on the recently merged patch [2] that added support for QEMU v10.0.0 aarch64 capabilities. For your convenience, this series is also available on Github [3]. [1] https://github.com/qemu/qemu/commit/f10104aeae3a17f181d5bb37b7fd7dad7fe86cba [2] https://github.com/nvmochs/libvirt/commit/cea2ee1d28780808172911e5c586478d4… [3] git fetch https://github.com/nvmochs/libvirt.git pci_highmem_mmio_size_pcihole64 Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com> Changelog: v3 - Patch 2 updates: + Use positive check in qemuBuildGlobalControllerCommandLine + Only allow pcihole64 for PCIe root controllers with arm virt - Added review tags from Daniel P. Berrangé for patch 1 and 3 v2 - Use existing XML scmhema (pcihole64 element) instead of a new one Matthew R. Ochs (3): qemu: Add capability for PCI high memory MMIO size qemu: Add command line support for PCI high memory MMIO size tests: Add pcihole64 test for virt machine src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 14 ++++++++- src/qemu/qemu_validate.c | 4 ++- .../caps_10.0.0_aarch64.xml | 1 + .../pcihole64-virt.aarch64-latest.args | 31 +++++++++++++++++++ .../pcihole64-virt.aarch64-latest.xml | 29 +++++++++++++++++ tests/qemuxmlconfdata/pcihole64-virt.xml | 17 ++++++++++ tests/qemuxmlconftest.c | 1 + 9 files changed, 98 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.xml -- 2.46.0

3 5

[PATCH] cpu_x86: Do not inline cpuidCall()
by Fabio Estevam 16 May '25

16 May '25

The following build error is observed with DEBUG_BUILD = 1: src/cpu/cpu_x86.c: In function 'cpuidSetLeaf4': src/cpu/cpu_x86.c:2563:1: error: inlining failed in call to 'cpuidCall': function not considered for inlining [-Werror=inline] 2563 | cpuidCall(virCPUx86CPUID *cpuid) | ^~~~~~~~~ Remove the 'inline' specifier to avoid the problem. Reported-by: Hongxu Jia <hongxu.jia(a)windriver.com> Signed-off-by: Fabio Estevam <festevam(a)gmail.com> --- src/cpu/cpu_x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c index 213af67ea478..0f7eb8f48b35 100644 --- a/src/cpu/cpu_x86.c +++ b/src/cpu/cpu_x86.c @@ -2564,7 +2564,7 @@ virCPUx86DataCheckFeature(const virCPUData *data, #if defined(__i386__) || defined(__x86_64__) -static inline void +static void cpuidCall(virCPUx86CPUID *cpuid) { virHostCPUX86GetCPUID(cpuid->eax_in, -- 2.34.1

3 3

[PATCH v2] cpu_x86: Do not inline cpuidCall()
by Fabio Estevam 16 May '25

16 May '25

The following build error is observed when the DEBUG_BUILD variable is enabled in OpenEmbedded: src/cpu/cpu_x86.c: In function 'cpuidSetLeaf4': src/cpu/cpu_x86.c:2563:1: error: inlining failed in call to 'cpuidCall': function not considered for inlining [-Werror=inline] 2563 | cpuidCall(virCPUx86CPUID *cpuid) | ^~~~~~~~~ Remove the 'inline' specifier to avoid the problem. Reported-by: Hongxu Jia <hongxu.jia(a)windriver.com> Signed-off-by: Fabio Estevam <festevam(a)gmail.com> Reviewed-by: Ján Tomko <jtomko(a)redhat.com> --- Changes since v1: - Improve the commit log by explaining where DEBUG_BUILD comes from. (Ján) src/cpu/cpu_x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c index 213af67ea478..0f7eb8f48b35 100644 --- a/src/cpu/cpu_x86.c +++ b/src/cpu/cpu_x86.c @@ -2564,7 +2564,7 @@ virCPUx86DataCheckFeature(const virCPUData *data, #if defined(__i386__) || defined(__x86_64__) -static inline void +static void cpuidCall(virCPUx86CPUID *cpuid) { virHostCPUX86GetCPUID(cpuid->eax_in, -- 2.34.1

1 0

[PATCH 0/2] spec: Bump min_rhel and min_fedora
by Michal Privoznik 16 May '25

16 May '25

Per our support policy [1], the minimal version we aim to support is RHEL-9 and Fedora 41. Reflect this in the spec file. 1: https://libvirt.org/platforms.html Michal Prívozník (2): spec: Bump min_rhel spec: Bump min_fedora libvirt.spec.in | 38 ++++++++++++-------------------------- 1 file changed, 12 insertions(+), 26 deletions(-) -- 2.49.0

2 3

[PATCH] ch: Support RNG device
by Stefan Kober 16 May '25

16 May '25

Cloud Hypervisor supports virtio-rng devices and the configuration of the randomness source (e.g. /dev/random or /dev/urandom). This commit adds support for configuring the RNG device via libvirt for the ch driver. Signed-off-by: Stefan Kober <stefan.kober(a)cyberus-technology.de> --- src/ch/ch_domain.c | 8 +++++++- src/ch/ch_monitor.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 1 deletion(-) diff --git a/src/ch/ch_domain.c b/src/ch/ch_domain.c index c0c9acd85b..7231fdc49f 100644 --- a/src/ch/ch_domain.c +++ b/src/ch/ch_domain.c @@ -163,6 +163,7 @@ chValidateDomainDeviceDef(const virDomainDeviceDef *dev, case VIR_DOMAIN_DEVICE_CONTROLLER: case VIR_DOMAIN_DEVICE_CHR: case VIR_DOMAIN_DEVICE_HOSTDEV: + case VIR_DOMAIN_DEVICE_RNG: break; case VIR_DOMAIN_DEVICE_LEASE: @@ -177,7 +178,6 @@ chValidateDomainDeviceDef(const virDomainDeviceDef *dev, case VIR_DOMAIN_DEVICE_SMARTCARD: case VIR_DOMAIN_DEVICE_MEMBALLOON: case VIR_DOMAIN_DEVICE_NVRAM: - case VIR_DOMAIN_DEVICE_RNG: case VIR_DOMAIN_DEVICE_SHMEM: case VIR_DOMAIN_DEVICE_TPM: case VIR_DOMAIN_DEVICE_PANIC: @@ -218,6 +218,12 @@ chValidateDomainDeviceDef(const virDomainDeviceDef *dev, return -1; } + if (def->nrngs > 1) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Only a single RNG device can be configured for this domain")); + return -1; + } + if (def->nserials > 1) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("Only a single serial can be configured for this domain")); diff --git a/src/ch/ch_monitor.c b/src/ch/ch_monitor.c index 5a490b75f6..3d3b4cb87d 100644 --- a/src/ch/ch_monitor.c +++ b/src/ch/ch_monitor.c @@ -302,6 +302,44 @@ virCHMonitorBuildDisksJson(virJSONValue *content, virDomainDef *vmdef) return 0; } +static int +virCHMonitorBuildRngJson(virJSONValue *content, virDomainDef *vmdef) +{ + g_autoptr(virJSONValue) rng = virJSONValueNewObject(); + + if (vmdef->nrngs == 0) { + return 0; + } + + if (vmdef->rngs[0]->model != VIR_DOMAIN_RNG_MODEL_VIRTIO) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Only virtio model is supported for RNG devices")); + return -1; + } + + switch (vmdef->rngs[0]->backend) { + case VIR_DOMAIN_RNG_BACKEND_RANDOM: + if (virJSONValueObjectAppendString(rng, "src", vmdef->rngs[0]->source.file) < 0) + return -1; + + if (virJSONValueObjectAppend(content, "rng", &rng) < 0) + return -1; + + break; + + case VIR_DOMAIN_RNG_BACKEND_EGD: + case VIR_DOMAIN_RNG_BACKEND_BUILTIN: + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Only RANDOM backend is supported for RNG devices")); + return -1; + + case VIR_DOMAIN_RNG_BACKEND_LAST: + break; + } + + return 0; +} + /** * virCHMonitorBuildNetJson: * @net: pointer to a guest network definition @@ -501,6 +539,9 @@ virCHMonitorBuildVMJson(virCHDriver *driver, virDomainDef *vmdef, if (virCHMonitorBuildDisksJson(content, vmdef) < 0) return -1; + if (virCHMonitorBuildRngJson(content, vmdef) < 0) + return -1; + if (virCHMonitorBuildDevicesJson(content, vmdef) < 0) return -1; -- 2.49.0

3 2

[PATCH 0/3] domain_capabilities: add console capabilities
by Roman Bogorodskiy 16 May '25

16 May '25

Motivation behind this series is to give management software possibility to check whether the 'pty' console could be used, or it should use something else, e.g. 'nmdm' for bhyve. Because of the complex relationships between 'serial' and 'console', I wasn't entirely sure whether I should report 'console' or 'serial'. Also, I wasn't sure if I needed to report anything but 'type'. Eventually I've decided to stay close to problem I'm trying to solve, and report only console types. I have updated only qemu and bhyve drivers for now, as I'm not sure if the approach is correct. I'll update other drivers if that's ok. Also, it was surprisingly tricky to get a list of supported console types for qemu, as the model is heavily shared between console, serials, parallel ports and channels, and sometimes it's not obvious if there's any difference between these devices' supported types. Interestingly, formatdomain.html doesn't provide much information about 'console type'. I was able to find the only occurrence of non-pty console, which is type='stdio'. I was able to find more console types used in the test data files though. Roman Bogorodskiy (3): domain_capabilities: add console capabilities bhyve: capabilities: report NMDM console qemu: 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/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 +++ .../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 +++++++++++ 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 +++++++++++ 68 files changed, 1119 insertions(+) -- 2.49.0

2 5

[PATCH 00/17] qemu: Fix regresion when loading internal snapshots and few cleanups
by Peter Krempa 16 May '25

16 May '25

This series: 1) Fixes the regression in loading internal snapshots: https://gitlab.com/libvirt/libvirt/-/issues/771 2) Fixes bugs in cleanup paths of snapshot reversion where we'd keep an inactive transient VM definition in the domain list (Noticed when debugging the former issue) 3) Cleans up qemu commandline generator of unneeded arguments for snapshot reversion after recent removal of old code 4) Renames the argument used to revert internal snapshots to something more obvious. 5) Cleans some unneeded passing of the qemu driver struct Peter Krempa (17): qemuProcessStartWithMemoryState: Don't setup qemu for incoming migration when reverting internal snapshot NEWS: Mention fix for internal snapshot reversion regression qemuSnapshotRevertActive: Remove transient domain on failure qemuSnapshotRevertInactive: Ensure all error paths handle transient domains properly qemuBuildCommandLine: Drop 'snapshot' argument qemuProcessLaunch: Rename 'snapshot' to 'internalSnapshotRevert' qemuProcessStart: Rename 'snapshot' to 'internalSnapshotRevert' qemuProcessStartWithMemoryState: Rename 'snapshot' to 'internalSnapshotRevert' qemuExtDevicesCleanupHost: Use 'virQEMUDriverConfig' instead of 'virQEMUDriver' qemuCheckpointDiscardAllMetadata: Remove 'driver' argument qemuSnapshotDiscardAllMetadata: Remove 'driver' argument qemuDomainRemoveInactiveCommon: Remove 'driver' argument qemuProcessStop: Drop 'driver' argument qemuDomainRemoveInactiveLocked: Remove 'driver' argument qemuProcessReconnect: Modernize local variable setup qemuProcessReconnectData: Drop 'driver' struct and clean up qemuDomainRemoveInactive: Remove 'driver' argument NEWS.rst | 10 ++++ src/qemu/qemu_checkpoint.c | 5 +- src/qemu/qemu_checkpoint.h | 3 +- src/qemu/qemu_command.c | 5 +- src/qemu/qemu_command.h | 1 - src/qemu/qemu_domain.c | 25 +++++----- src/qemu/qemu_domain.h | 6 +-- src/qemu/qemu_driver.c | 46 ++++++++---------- src/qemu/qemu_extdevice.c | 18 +++---- src/qemu/qemu_extdevice.h | 4 +- src/qemu/qemu_migration.c | 20 ++++---- src/qemu/qemu_process.c | 98 +++++++++++++++++++------------------- src/qemu/qemu_process.h | 7 ++- src/qemu/qemu_saveimage.c | 2 +- src/qemu/qemu_snapshot.c | 75 ++++++++++++++--------------- src/qemu/qemu_snapshot.h | 3 +- src/qemu/qemu_tpm.c | 14 ++---- src/qemu/qemu_tpm.h | 4 +- 18 files changed, 167 insertions(+), 179 deletions(-) -- 2.49.0

3 20

[PATCH] ci: refresh with 'lcitool manifest'
by Michal Privoznik 16 May '25

16 May '25

From: Michal Privoznik <mprivozn(a)redhat.com> - Add Fedora 42 - Remove EOL Fedora 40 - Switch mingw from Fedora 41 to Fedora 42 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Green pipeline: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1819375318 It also contains spec file changes that I'll be sending shortly. I have them all in one branch. ...-mingw32.sh => fedora-42-cross-mingw32.sh} | 0 ...-mingw64.sh => fedora-42-cross-mingw64.sh} | 0 ci/buildenv/{fedora-40.sh => fedora-42.sh} | 3 +- ...ile => fedora-42-cross-mingw32.Dockerfile} | 2 +- ...ile => fedora-42-cross-mingw64.Dockerfile} | 2 +- ...ora-40.Dockerfile => fedora-42.Dockerfile} | 5 +- ci/gitlab/builds.yml | 46 +++++++++---------- ci/gitlab/containers.yml | 22 ++++----- ci/manifest.yml | 16 +++---- 9 files changed, 49 insertions(+), 47 deletions(-) rename ci/buildenv/{fedora-41-cross-mingw32.sh => fedora-42-cross-mingw32.sh} (100%) rename ci/buildenv/{fedora-41-cross-mingw64.sh => fedora-42-cross-mingw64.sh} (100%) rename ci/buildenv/{fedora-40.sh => fedora-42.sh} (97%) rename ci/containers/{fedora-41-cross-mingw32.Dockerfile => fedora-42-cross-mingw32.Dockerfile} (98%) rename ci/containers/{fedora-41-cross-mingw64.Dockerfile => fedora-42-cross-mingw64.Dockerfile} (98%) rename ci/containers/{fedora-40.Dockerfile => fedora-42.Dockerfile} (96%) diff --git a/ci/buildenv/fedora-41-cross-mingw32.sh b/ci/buildenv/fedora-42-cross-mingw32.sh similarity index 100% rename from ci/buildenv/fedora-41-cross-mingw32.sh rename to ci/buildenv/fedora-42-cross-mingw32.sh diff --git a/ci/buildenv/fedora-41-cross-mingw64.sh b/ci/buildenv/fedora-42-cross-mingw64.sh similarity index 100% rename from ci/buildenv/fedora-41-cross-mingw64.sh rename to ci/buildenv/fedora-42-cross-mingw64.sh diff --git a/ci/buildenv/fedora-40.sh b/ci/buildenv/fedora-42.sh similarity index 97% rename from ci/buildenv/fedora-40.sh rename to ci/buildenv/fedora-42.sh index e45ac2230f..c32a689fbd 100644 --- a/ci/buildenv/fedora-40.sh +++ b/ci/buildenv/fedora-42.sh @@ -9,7 +9,7 @@ function install_buildenv() { dnf install -y \ audit-libs-devel \ augeas \ - bash-completion \ + bash-completion-devel \ ca-certificates \ ccache \ clang \ @@ -82,6 +82,7 @@ function install_buildenv() { systemd-devel \ systemd-rpm-macros \ systemtap-sdt-devel \ + systemtap-sdt-dtrace \ wireshark-devel \ xen-devel rm -f /usr/lib*/python3*/EXTERNALLY-MANAGED diff --git a/ci/containers/fedora-41-cross-mingw32.Dockerfile b/ci/containers/fedora-42-cross-mingw32.Dockerfile similarity index 98% rename from ci/containers/fedora-41-cross-mingw32.Dockerfile rename to ci/containers/fedora-42-cross-mingw32.Dockerfile index 6ab14be6fc..5689128ed9 100644 --- a/ci/containers/fedora-41-cross-mingw32.Dockerfile +++ b/ci/containers/fedora-42-cross-mingw32.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:41 +FROM registry.fedoraproject.org/fedora:42 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ diff --git a/ci/containers/fedora-41-cross-mingw64.Dockerfile b/ci/containers/fedora-42-cross-mingw64.Dockerfile similarity index 98% rename from ci/containers/fedora-41-cross-mingw64.Dockerfile rename to ci/containers/fedora-42-cross-mingw64.Dockerfile index a0ec65d74a..dff7d84fa3 100644 --- a/ci/containers/fedora-41-cross-mingw64.Dockerfile +++ b/ci/containers/fedora-42-cross-mingw64.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:41 +FROM registry.fedoraproject.org/fedora:42 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ diff --git a/ci/containers/fedora-40.Dockerfile b/ci/containers/fedora-42.Dockerfile similarity index 96% rename from ci/containers/fedora-40.Dockerfile rename to ci/containers/fedora-42.Dockerfile index b82a975bdb..a59c7beb41 100644 --- a/ci/containers/fedora-40.Dockerfile +++ b/ci/containers/fedora-42.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM registry.fedoraproject.org/fedora:40 +FROM registry.fedoraproject.org/fedora:42 RUN dnf install -y nosync && \ printf '#!/bin/sh\n\ @@ -20,7 +20,7 @@ exec "$@"\n' > /usr/bin/nosync && \ nosync dnf install -y \ audit-libs-devel \ augeas \ - bash-completion \ + bash-completion-devel \ ca-certificates \ ccache \ clang \ @@ -93,6 +93,7 @@ exec "$@"\n' > /usr/bin/nosync && \ systemd-devel \ systemd-rpm-macros \ systemtap-sdt-devel \ + systemtap-sdt-dtrace \ wireshark-devel \ xen-devel && \ nosync dnf autoremove -y && \ diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index 893843cb64..5fab2008d8 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -103,21 +103,6 @@ x86_64-debian-sid: TARGET_BASE_IMAGE: docker.io/library/debian:sid-slim -x86_64-fedora-40: - extends: .native_build_job - needs: - - job: x86_64-fedora-40-container - optional: true - allow_failure: false - variables: - NAME: fedora-40 - TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:40 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - - x86_64-fedora-41: extends: .native_build_job needs: @@ -133,6 +118,21 @@ x86_64-fedora-41: - libvirt-rpms +x86_64-fedora-42: + extends: .native_build_job + needs: + - job: x86_64-fedora-42-container + optional: true + allow_failure: false + variables: + NAME: fedora-42 + TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:42 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + + x86_64-fedora-rawhide: extends: .native_build_job needs: @@ -416,29 +416,29 @@ s390x-debian-sid: TARGET_BASE_IMAGE: docker.io/library/debian:sid-slim -mingw32-fedora-41: +mingw32-fedora-42: extends: .cross_build_job needs: - - job: mingw32-fedora-41-container + - job: mingw32-fedora-42-container optional: true allow_failure: false variables: CROSS: mingw32 JOB_OPTIONAL: 1 - NAME: fedora-41 - TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:41 + NAME: fedora-42 + TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:42 -mingw64-fedora-41: +mingw64-fedora-42: extends: .cross_build_job needs: - - job: mingw64-fedora-41-container + - job: mingw64-fedora-42-container optional: true allow_failure: false variables: CROSS: mingw64 - NAME: fedora-41 - TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:41 + NAME: fedora-42 + TARGET_BASE_IMAGE: registry.fedoraproject.org/fedora:42 mingw32-fedora-rawhide: diff --git a/ci/gitlab/containers.yml b/ci/gitlab/containers.yml index f88a39a1f8..05809fbdeb 100644 --- a/ci/gitlab/containers.yml +++ b/ci/gitlab/containers.yml @@ -49,13 +49,6 @@ x86_64-debian-sid-container: NAME: debian-sid -x86_64-fedora-40-container: - extends: .container_job - allow_failure: false - variables: - NAME: fedora-40 - - x86_64-fedora-41-container: extends: .container_job allow_failure: false @@ -63,6 +56,13 @@ x86_64-fedora-41-container: NAME: fedora-41 +x86_64-fedora-42-container: + extends: .container_job + allow_failure: false + variables: + NAME: fedora-42 + + x86_64-fedora-rawhide-container: extends: .container_job allow_failure: true @@ -220,19 +220,19 @@ s390x-debian-sid-container: NAME: debian-sid-cross-s390x -mingw32-fedora-41-container: +mingw32-fedora-42-container: extends: .container_job allow_failure: false variables: JOB_OPTIONAL: 1 - NAME: fedora-41-cross-mingw32 + NAME: fedora-42-cross-mingw32 -mingw64-fedora-41-container: +mingw64-fedora-42-container: extends: .container_job allow_failure: false variables: - NAME: fedora-41-cross-mingw64 + NAME: fedora-42-cross-mingw64 mingw32-fedora-rawhide-container: diff --git a/ci/manifest.yml b/ci/manifest.yml index 3b06f4827e..14bfef25d2 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -104,14 +104,6 @@ targets: containers: false builds: false - fedora-40: - jobs: - - arch: x86_64 - artifacts: - expire_in: 1 day - paths: - - libvirt-rpms - fedora-41: jobs: - arch: x86_64 @@ -120,6 +112,14 @@ targets: paths: - libvirt-rpms + fedora-42: + jobs: + - arch: x86_64 + artifacts: + expire_in: 1 day + paths: + - libvirt-rpms + - arch: mingw32 builds: false -- 2.49.0

2 1

[PATCH v3 0/6] qemu: acpi-generic-initiator support
by Andrea Righi 16 May '25

16 May '25

= Overview = This patch set introduces support for acpi-generic-initiator devices, supported by QEMU [1]. The acpi-generic-initiator object is required to support Multi-Instance GPU (MIG) configurations on NVIDIA GPUs [2]. MIG enables partitioning of GPU resources into multiple isolated instances, each requiring a dedicated NUMA node definition. = Implementation = This patch set implements the libvirt counterpart to the QEMU feature, enabling users to configure acpi-generic-initiator objects within libvirt domain XML. This includes: - adding XML syntax to define acpi-generic-initiator objects, - resolving the acpi-generic-initiator definitions into the proper QEMU command-line arguments, - ensuring compatibility with existing NUMA configuration. = Example = - Domain XML: ``` ... <cpu mode='host-passthrough' check='none'> <numa> <cell id='0' cpus='0-15' memory='8388608' unit='KiB'/> <cell id='1' memory='0' unit='KiB'/> <cell id='2' memory='0' unit='KiB'/> <cell id='3' memory='0' unit='KiB'/> <cell id='4' memory='0' unit='KiB'/> <cell id='5' memory='0' unit='KiB'/> <cell id='6' memory='0' unit='KiB'/> <cell id='7' memory='0' unit='KiB'/> <cell id='8' memory='0' unit='KiB'/> </numa> </cpu> ... <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <acpi-generic-initiator> <alias name="gi1"/> <pci-dev>hostdev0</pci-dev> <numa-node>1</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi2"/> <pci-dev>hostdev0</pci-dev> <numa-node>2</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi3"/> <pci-dev>hostdev0</pci-dev> <numa-node>3</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi4"/> <pci-dev>hostdev0</pci-dev> <numa-node>4</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi5"/> <pci-dev>hostdev0</pci-dev> <numa-node>5</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi6"/> <pci-dev>hostdev0</pci-dev> <numa-node>6</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi7"/> <pci-dev>hostdev0</pci-dev> <numa-node>7</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <alias name="gi8"/> <pci-dev>hostdev0</pci-dev> <numa-node>8</numa-node> </acpi-generic-initiator> </devices> ``` - Generated QEMU command line options: ``` ... /usr/bin/qemu-system-aarch64 \ ... -object '{"qom-type":"memory-backend-ram","id":"ram-node0","size":8589934592}' \ -numa node,nodeid=0,cpus=0-15,memdev=ram-node0 \ -numa node,nodeid=1 \ -numa node,nodeid=2 \ -numa node,nodeid=3 \ -numa node,nodeid=4 \ -numa node,nodeid=5 \ -numa node,nodeid=6 \ -numa node,nodeid=7 \ -numa node,nodeid=8 \ ... -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","bus":"pci.3","addr":"0x0"}' ... -object acpi-generic-initiator,id=gi1,pci-dev=hostdev0,node=1 \ -object acpi-generic-initiator,id=gi2,pci-dev=hostdev0,node=2 \ -object acpi-generic-initiator,id=gi3,pci-dev=hostdev0,node=3 \ -object acpi-generic-initiator,id=gi4,pci-dev=hostdev0,node=4 \ -object acpi-generic-initiator,id=gi5,pci-dev=hostdev0,node=5 \ -object acpi-generic-initiator,id=gi6,pci-dev=hostdev0,node=6 \ -object acpi-generic-initiator,id=gi7,pci-dev=hostdev0,node=7 \ -object acpi-generic-initiator,id=gi8,pci-dev=hostdev0,node=8 ``` = References = [1] https://lore.kernel.org/all/20231225045603.7654-2-ankita@nvidia.com/ [2] https://www.nvidia.com/en-in/technologies/multi-instance-gpu/ ChangeLog v2 -> v3: - replaced <text/> with proper types in the XML schema - avoid mixing g_free() and VIR_FREE() - use virXMLPropString() instead of looping all XML nodes - report proper errors with virReportError() - use virBufferEscapeString() to process strings passed by the user - fix broken formatting of function headers - misc coding style fixes ChangeLog v1 -> v2: - split parser and driver changes in separate patches - introduce a new qemu capability flag - introduce test in qemuxmlconftest Andrea Righi (6): schema: Introduce acpi-generic-initiator definition conf: Introduce acpi-generic-initiator device qemu: Allow to define NUMA nodes without memory or CPUs assigned qemu: capabilies: Introduce QEMU_CAPS_ACPI_GENERIC_INITIATOR qemu: support acpi-generic-initiator qemu: Add test case for acpi-generic-initiator src/ch/ch_domain.c | 1 + src/conf/domain_conf.c | 159 +++++++++++++++++++++ src/conf/domain_conf.h | 14 ++ src/conf/domain_postparse.c | 1 + src/conf/domain_validate.c | 37 +++++ src/conf/numa_conf.c | 3 + src/conf/schemas/domaincommon.rng | 19 +++ src/conf/virconftypes.h | 2 + src/libxl/libxl_driver.c | 6 + src/lxc/lxc_driver.c | 6 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 49 ++++++- src/qemu/qemu_domain.c | 2 + src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_driver.c | 3 + src/qemu/qemu_hotplug.c | 5 + src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 1 + src/test/test_driver.c | 4 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.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_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 1 + .../acpi-generic-initiator.x86_64-latest.args | 55 +++++++ .../acpi-generic-initiator.x86_64-latest.xml | 102 +++++++++++++ tests/qemuxmlconfdata/acpi-generic-initiator.xml | 102 +++++++++++++ tests/qemuxmlconftest.c | 1 + 32 files changed, 581 insertions(+), 7 deletions(-) create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/acpi-generic-initiator.xml

3 12

[PATCH v2 0/3] Add virt machine support for configuring PCI high memory MMIO size
by Matthew R. Ochs 15 May '25

15 May '25

This patch series adds support for configuring the PCI high memory MMIO window size for aarch64 virt machine types using the highmem-mmio-size feature introduced in QEMU v10.0.0 [1]. It allows users to configure the size of the high memory MMIO window above 4GB, which can be required to support PCI passthrough with devices that have a large BARs. The feature is exposed through the existing pcihole64 element associated with the PCIe root controller: <controller type='pci' index='0' model='pcie-root'> <pcihole64 unit='GiB'>512</pcihole64> </controller> This existing schema supports the same semantics for the QEMU PC machine pci-hole64-size parameter and is a natural fit for supporting the highmem-mmio-size feature on the aarch64 virt machine. This series is applied over master and depends on the recently merged patch [2] that added support for QEMU v10.0.0 aarch64 capabilities. For your convenience, this series is also available on Github [3]. [1] https://github.com/qemu/qemu/commit/f10104aeae3a17f181d5bb37b7fd7dad7fe86cba [2] https://github.com/nvmochs/libvirt/commit/cea2ee1d28780808172911e5c586478d4… [3] git fetch https://github.com/nvmochs/libvirt.git pci_highmem_mmio_size_pcihole64 Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com> Changelog: v2 - Use existing XML scmhema (pcihole64 element) instead of a new one Matthew R. Ochs (3): qemu: Add capability for PCI high memory MMIO size qemu: Add command line support for PCI high memory MMIO size tests: Add pcihole64 test for virt machine src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 14 ++++++++- src/qemu/qemu_validate.c | 8 +++-- .../caps_10.0.0_aarch64.xml | 1 + .../pcihole64-virt.aarch64-latest.args | 31 +++++++++++++++++++ .../pcihole64-virt.aarch64-latest.xml | 29 +++++++++++++++++ tests/qemuxmlconfdata/pcihole64-virt.xml | 17 ++++++++++ tests/qemuxmlconftest.c | 1 + 9 files changed, 101 insertions(+), 3 deletions(-) create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/pcihole64-virt.xml -- 2.46.0

3 7

[PATCH v3 0/1] rpc: Re-read the data if EAGAIN or EINTR were captured
by yong.huang＠smartx.com 15 May '25

15 May '25

From: Hyman Huang <yong.huang(a)smartx.com> v3: Add the overlooked Signed-off-by v2: 1. Move the retry logic outside of virNetTLSSession{Read,Write} 2. Try re-polling when handing EAGAIN suggested by Daniel v1: 1. Encapsulate the retry logic inside virNetTLSSession{Read,Write} 2. Use VIR_DEBUG instead of VIR_WARN to log the retry operation rfc: https://patchew.org/Libvirt/d716a59dc2c61916917c6d2e07d62055745606d5.174404… Please review, thanks. Yong Hyman Huang (1): rpc: Add the {repoll,retry} logic in virNetClientSetTLSSession src/rpc/virnetclient.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.27.0

2 2