- Devel - libvirt List Archives

[PATCH] NEWS: Document features/improvements/bug fixes I've participated in
by Michal Privoznik 30 Jun '25

30 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> There are some features/improvements/bug fixes I've either contributed or reviewed/merged. Document them for upcoming release. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- NEWS.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 184df16547..ee4e9a022e 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -60,6 +60,12 @@ v11.5.0 (unreleased) * **Bug fixes** + * qemu: Be more forgiving when acquiring QUERY job when formatting domain XML + + Since ``libvirt-11.0.0`` the ``virDomainGetXMLDesc()`` API used to format + domain XML acquires QUERY job. But this caused a regression when the API + might timeout for incoming migration. This is now fixed. + v11.4.0 (2025-06-02) ==================== -- 2.49.0

2 1

Re: [PATCH v3 2/2] virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks
by Michal Prívozník 30 Jun '25

30 Jun '25

On 6/25/25 18:49, Tim Small wrote: > > > On 09/06/2025 13:51, Michal Prívozník wrote: > >> But this new IPC got me thinking - the XML we're parsing here in the aa >> helper is formatted by libvirtd who already know the actual type of each >> net. But looking into the code - this is lost when the daemon talks to >> the helper. I'm not on an AppArmor machine right now, so can you please >> check whether the following change (applied on the top of this very >> patch) works? It would save us from those IPCs. > > Thanks Michal. The additional patches which you posted (below) did not > work in isolation, but with an additional change to the src/qemu/ > qemu_process.c to ensure that the network is resolved before the > apparmor helper is called, it works. > > I've updated my branch and tested, and will post the updated patch to > the mailing list, but before I do-so... > > What would you like me to do with regard to the changes with you proposed? > > . Post with credit in the patch commentary. > . Post with credit in the commit message. If you want, then you can put Suggested-by: Michal Privoznik <mprivozn(a)redhat.com> line just above your SoB line. Thanks! > . Something else? > > Thanks for the tip! No problem. Introducing new RPC call always sets my alarm off :-D Michal

1 0

Entering freeze for libvirt-11.5.0
by Jiri Denemark 27 Jun '25

27 Jun '25

I have just tagged v11.5.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Jirka

2 1

[PATCH v4 0/8] qemu: acpi-generic-initiator support
by Andrea Righi 27 Jun '25

27 Jun '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> <pci-dev>hostdev0</pci-dev> <numa-node>1</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>2</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>3</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>4</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>5</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>6</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <pci-dev>hostdev0</pci-dev> <numa-node>7</numa-node> </acpi-generic-initiator> <acpi-generic-initiator> <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=gi0,pci-dev=hostdev0,node=1 \ -object acpi-generic-initiator,id=gi1,pci-dev=hostdev0,node=2 \ -object acpi-generic-initiator,id=gi2,pci-dev=hostdev0,node=3 \ -object acpi-generic-initiator,id=gi3,pci-dev=hostdev0,node=4 \ -object acpi-generic-initiator,id=gi4,pci-dev=hostdev0,node=5 \ -object acpi-generic-initiator,id=gi5,pci-dev=hostdev0,node=6 \ -object acpi-generic-initiator,id=gi6,pci-dev=hostdev0,node=7 \ -object acpi-generic-initiator,id=gi7,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/ This patchset is also available in the following git branch: https://github.com/arighi/libvirt.git acpi-generic-initiator-v4 ChangeLog v3 -> v4: - add acpi-generic-initiator documentation - refactor virDomainAcpiInitiatorDef to use info->alias and drop the name attribute - auto-generate alias for the acpi-generic-initiator devices via qemuAssignDeviceAliases() - use g_autoptr() when possible - add a new entry to NEWS.rst 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 (8): 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 docs: Document acpi-generic-initiator device NEWS: Mention new acpi-generic-initiator device NEWS.rst | 8 ++ docs/formatdomain.rst | 36 ++++++ src/ch/ch_domain.c | 1 + src/conf/domain_conf.c | 138 +++++++++++++++++++++ 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 | 14 +++ src/conf/virconftypes.h | 2 + src/hyperv/hyperv_driver.c | 1 + src/libxl/libxl_driver.c | 6 + src/lxc/lxc_driver.c | 6 + src/qemu/qemu_alias.c | 11 ++ 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 + tests/qemucapabilitiesdata/caps_10.0.0_aarch64.xml | 1 + .../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 | 94 ++++++++++++++ tests/qemuxmlconfdata/acpi-generic-initiator.xml | 94 ++++++++++++++ tests/qemuxmlconftest.c | 1 + 37 files changed, 596 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

2 14

[PATCH 0/4] USB hostdev: allow addressing by port
by Maximilian Martin 27 Jun '25

27 Jun '25

This resubmission splits up the previous patch into multiple patches and incorporates review comments from Michal Prívozník. Currently, only vendor/product and bus/device matching are supported for USB host devices. Neither of these provide a stable and persistent way of assigning a guest a specific host device. Vendor/product can be ambiguous. Device numbers change on every enumeration. This patch adds a bus/port matching, which allows a specific port on the host to be specified using the dotted notation found in Linux's "devpath" sysfs attribute. This patch is based on the previous work of Thomas Hebb: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/7U3… Resolves: https://gitlab.com/libvirt/libvirt/-/issues/513 Signed-off-by: Maximilian Martin <maximilian_martin(a)gmx.de> Maximilian Martin (4): virusb test data: add devpath files for port addressing domain_conf, virhostdev, virusb, virusb test: add bus/port matching schema: add USB port attribute docs: add description for USB port matching docs/formatdomain.rst | 29 ++-- src/conf/domain_conf.c | 69 +++++++- src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 11 +- src/hypervisor/virhostdev.c | 131 +++++++++------ src/libvirt_private.syms | 2 - src/util/virusb.c | 156 ++++++------------ src/util/virusb.h | 32 ++-- tests/virusbtest.c | 149 ++++++++++++----- .../sys_bus_usb/devices/1-1.5.3.1/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.3/devpath | 1 + .../sys_bus_usb/devices/1-1.5.4/devpath | 1 + .../sys_bus_usb/devices/1-1.5.5/devpath | 1 + .../sys_bus_usb/devices/1-1.5.6/devpath | 1 + .../sys_bus_usb/devices/1-1.5/devpath | 1 + .../sys_bus_usb/devices/1-1.6/devpath | 1 + .../sys_bus_usb/devices/1-1/devpath | 1 + .../sys_bus_usb/devices/2-1.2/devpath | 1 + .../sys_bus_usb/devices/2-1/devpath | 1 + .../sys_bus_usb/devices/usb1/devpath | 1 + .../sys_bus_usb/devices/usb2/devpath | 1 + .../sys_bus_usb/devices/usb3/devpath | 1 + .../sys_bus_usb/devices/usb4/devpath | 1 + 24 files changed, 351 insertions(+), 244 deletions(-) create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.4/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.5/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1.6/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/1-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1.2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/2-1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb1/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb2/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb3/devpath create mode 100644 tests/virusbtestdata/sys_bus_usb/devices/usb4/devpath -- 2.39.5

3 16

[PATCH v2 00/21] LIBVIRT: X86: TDX support
by Zhenzhong Duan 27 Jun '25

27 Jun '25

Hi, This series brings libvirt the x86 TDX support. * What's TDX? TDX stands for Trust Domain Extensions which isolates VMs from the virtual-machine manager (VMM)/hypervisor and any other software on the platform. This patchset extends libvirt to support TDX, with which one can start a TDX guest from high level rather than running qemu directly. * Misc As QEMU use a software emulated way to reset guest which isn't supported by TDX guest for security reason. We simulate reboot for TDX guest by kill and create a new one in FakeReboot framework. Complete code can be found at [1]. * Test Tested with upstream qemu v10.0.0-1724-gf9a3def17b shutdown/reboot/reset with virsh shutdown/reboot trigger in guest shutdown with on_poweroff=destroy/restart reboot with on_reboot=destroy/restart * Patch organization - patch 1-4: Support query of TDX capabilities - patch 5-11: Add TDX type to launchsecurity framework - patch 12-17: Add reboot/reset support to TDX guest - patch 18-20: Add test data/cases - patch 21: Add docs TODO: - add reconnect logic in virsh command [1] https://github.com/intel/libvirt-tdx/commits/tdx_for_upstream_v2 Thanks Zhenzhong Changelog: v2: - add capability and xmlconf test (Peter Krempa) v1: - s/virQEMUCapsKVMSupportsSecureGuestINTEL/virQEMUCapsKVMSupportsSecureGuestTDX (Daniel) - make policy element optional and expose to QEMU directly (Daniel) - s/qemuProcessSecFakeReboot/qemuProcessFakeRebootViaRecreate (Daniel) - simplify QGS element schema by supporting only UNIX socket (Daniel) - add new events VIR_DOMAIN_EVENT_[STOPPED|STARTED] for control plane (Daniel) - s/quoteGenerationService/quoteGenerationSocket as QEMU - add virsh reset support rfcv4: - add a check to tools/virt-host-validate-qemu.c (Daniel) - remove check of q35 (Daniel) - model 'SocktetAddress' QAPI in xml schema (Daniel) - s/Quote-Generation-Service/quoteGenerationService/ (Daniel) - define bits in tdx->policy and add validating logic (Daniel) - presume QEMU choose split kernel irqchip for TDX guest by default (Daniel) - utilize existing FakeReboot framework to do reboot for TDX guest (Daniel) - drop patch11 'conf: Add support to keep same domid for hard reboot' (Daniel) - add test in tests/ to validate parsing and formatting logic (Daniel) - add doc in docs/formatdomain.rst (Daniel) - add R-B rfcv3: - Change to generate qemu cmdline with -bios - drop firmware auto match as -bios is used - add a hard reboot method to reboot TDX guest rfcv3: https://www.mail-archive.com/devel@lists.libvirt.org/msg00385.html rfcv2: - give up using qmp cmd and check TDX directly on host for TDX capabilities. - use launchsecurity framework to support TDX - use <os>.<loader> for general loader - add auto firmware match feature for TDX A example TDVF fimware description file 70-edk2-x86_64-tdx.json: { "description": "UEFI firmware for x86_64, supporting Intel TDX", "interface-types": [ "uefi" ], "mapping": { "device": "generic", "filename": "/usr/share/OVMF/OVMF_CODE-tdx.fd" }, "targets": [ { "architecture": "x86_64", "machines": [ "pc-q35-*" ] } ], "features": [ "intel-tdx", "verbose-dynamic" ], "tags": [ ] } rfcv2: https://www.mail-archive.com/libvir-list@redhat.com/msg219378.html Zhenzhong Duan (21): tools: Secure guest check for Intel in virt-host-validate qemu: Check if INTEL Trust Domain Extention support is enabled qemu: Add TDX capability conf: Expose TDX feature in domain capabilities conf: Add tdx as launch security type conf: Validate TDX launchSecurity element mrConfigId/mrOwner/mrOwnerConfig qemu: Add command line and validation for TDX type conf: Expose TDX type in domain launch security capability qemu: Force special parameters enabled for TDX guest conf: Add Intel TDX Quote Generation Service(QGS) support qemu: Add command line for TDX Quote Generation Service(QGS) qemu: Add FakeReboot support for TDX guest qemu: Support reboot command in guest qemu: Avoid duplicate FakeReboot for secure guest qemu: Send event VIR_DOMAIN_EVENT_[STOPPED|STARTED] during recreation qemu: Bypass sending VIR_DOMAIN_EVENT_RESUMED event when TD VM reboot qemu: Support domain reset command for TDX guest qemucapabilitiesdata: Document '+inteltdx' variant qemucapabilitiestest: Add data for the qemu-11.0 dev cycle on x86_64 for the '+inteltdx' variant qemuxmlconftest: Add latest version of 'launch-security-tdx*' test data docs: domain: Add documentation for Intel TDX guest docs/formatdomain.rst | 63 + docs/formatdomaincaps.rst | 1 + examples/c/misc/event-test.c | 6 + include/libvirt/libvirt-domain.h | 2 + src/conf/domain_capabilities.c | 1 + src/conf/domain_capabilities.h | 1 + src/conf/domain_conf.c | 82 + src/conf/domain_conf.h | 21 + src/conf/domain_validate.c | 11 + src/conf/schemas/domaincaps.rng | 9 + src/conf/schemas/domaincommon.rng | 41 + src/conf/virconftypes.h | 2 + src/qemu/qemu_capabilities.c | 38 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 1 + src/qemu/qemu_command.c | 54 + src/qemu/qemu_driver.c | 7 + src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 28 +- src/qemu/qemu_monitor.h | 2 +- src/qemu/qemu_monitor_json.c | 6 +- src/qemu/qemu_namespace.c | 1 + src/qemu/qemu_process.c | 104 +- src/qemu/qemu_process.h | 2 + src/qemu/qemu_validate.c | 45 + src/security/security_dac.c | 2 + .../qemu_11.0.0-q35.x86_64+inteltdx.xml | 782 + .../qemu_11.0.0-tcg.x86_64+inteltdx.xml | 1830 + .../qemu_11.0.0.x86_64+inteltdx.xml | 782 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_11.0.0_x86_64+inteltdx.replies | 44552 ++++++++++++++++ .../caps_11.0.0_x86_64+inteltdx.xml | 3585 ++ .../caps.x86_64+inteltdx.xml | 29 + ...h-security-tdx.x86_64-latest+inteltdx.args | 44 + ...ch-security-tdx.x86_64-latest+inteltdx.xml | 74 + tests/qemuxmlconfdata/launch-security-tdx.xml | 27 + tests/qemuxmlconftest.c | 3 + tools/virsh-domain-event.c | 6 +- tools/virt-host-validate-common.c | 31 +- tools/virt-host-validate-common.h | 1 + 40 files changed, 52270 insertions(+), 13 deletions(-) create mode 100644 tests/domaincapsdata/qemu_11.0.0-q35.x86_64+inteltdx.xml create mode 100644 tests/domaincapsdata/qemu_11.0.0-tcg.x86_64+inteltdx.xml create mode 100644 tests/domaincapsdata/qemu_11.0.0.x86_64+inteltdx.xml create mode 100644 tests/qemucapabilitiesdata/caps_11.0.0_x86_64+inteltdx.replies create mode 100644 tests/qemucapabilitiesdata/caps_11.0.0_x86_64+inteltdx.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+inteltdx.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.args create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.x86_64-latest+inteltdx.xml create mode 100644 tests/qemuxmlconfdata/launch-security-tdx.xml -- 2.34.1

4 33

[PATCH v3] remote/stream-event: Fix a memory leak in remoteStreamCallbackFree()
by liu.xuemei1＠zte.com.cn 27 Jun '25

27 Jun '25

From: Liu Song <liu.song13(a)zte.com.cn> The ff callback is never called in remoteStreamCallbackFree() because cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'. The leak can be reproduced by attaching and detaching to the console of an VM using `virsh console`. ASAN reports the leak stack as: Direct leak of 288 byte(s) in 1 object(s) allocated from: #0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7) #1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0) #2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3) #3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf) #4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877) #5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620) #6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252 #7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274 #8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369 #9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427 Signed-off-by: Liu Song <liu.song13(a)zte.com.cn> --- Changes in v3: - Remove the second reference to 'client', and unref 'client' in error path. src/remote/remote_daemon_stream.c | 7 ++++--- src/remote/remote_driver.c | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 453728a66b..b6099e3bc7 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -437,12 +437,13 @@ int daemonAddClientStream(virNetServerClient *client, return -1; } + virObjectRef(client); if (virStreamEventAddCallback(stream->st, 0, daemonStreamEvent, client, - virObjectUnref) < 0) + virObjectUnref) < 0) { + virObjectUnref(client); return -1; - - virObjectRef(client); + } if ((stream->filterID = virNetServerClientAddFilter(client, daemonStreamFilter, diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 2690c05267..9ac13469e9 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque) { struct remoteStreamCallbackData *cbdata = opaque; - if (!cbdata->cb && cbdata->ff) + if (cbdata->ff) (cbdata->ff)(cbdata->opaque); virObjectUnref(cbdata->st); -- 2.27.0

1 0

Re: [PATCH] remote/stream-event: Fix a memory leak in?? remoteStreamCallbackFree()
by Bjorn Helgaas 26 Jun '25

26 Jun '25

[+to libvirt development list, since this looks like a libvirt patch, not a Linux kernel patch] On Thu, Jun 26, 2025 at 02:10:38PM +0800, liu.xuemei1(a)zte.com.cn wrote: > From: Liu Song <liu.song13(a)zte.com.cn> > > The ff callback is never called in remoteStreamCallbackFree() because > cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'. > > The leak can be reproduced by attaching and detaching to the console of > an VM using `virsh console`. > > ASAN reports the leak stack as: > Direct leak of 288 byte(s) in 1 object(s) allocated from: > #0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7) > #1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0) > #2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3) > #3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf) > #4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877) > #5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620) > #6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252 > #7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274 > #8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369 > #9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427 > > Signed-off-by: Liu Song <liu.song13(a)zte.com.cn> > --- > src/remote/remote_daemon_stream.c | 2 +- > src/remote/remote_driver.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c > index 453728a66b..a5032f9a43 100644 > --- a/src/remote/remote_daemon_stream.c > +++ b/src/remote/remote_daemon_stream.c > @@ -437,13 +437,13 @@ int daemonAddClientStream(virNetServerClient *client, > return -1; > } > > + virObjectRef(client); > if (virStreamEventAddCallback(stream->st, 0, > daemonStreamEvent, client, > virObjectUnref) < 0) > return -1; > > virObjectRef(client); > - > if ((stream->filterID = virNetServerClientAddFilter(client, > daemonStreamFilter, > stream)) < 0) { > diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c > index 2690c05267..9ac13469e9 100644 > --- a/src/remote/remote_driver.c > +++ b/src/remote/remote_driver.c > @@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque) > { > struct remoteStreamCallbackData *cbdata = opaque; > > - if (!cbdata->cb && cbdata->ff) > + if (cbdata->ff) > (cbdata->ff)(cbdata->opaque); > > virObjectUnref(cbdata->st); > -- > 2.27.0

1 0

[PATCH v2] remote/stream-event: Fix a memory leak in remoteStreamCallbackFree()
by liu.xuemei1＠zte.com.cn 26 Jun '25

26 Jun '25

From: Liu Song <liu.song13(a)zte.com.cn> The ff callback is never called in remoteStreamCallbackFree() because cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'. The leak can be reproduced by attaching and detaching to the console of an VM using `virsh console`. ASAN reports the leak stack as: Direct leak of 288 byte(s) in 1 object(s) allocated from: #0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7) #1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0) #2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3) #3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf) #4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877) #5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620) #6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252 #7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274 #8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369 #9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427 Signed-off-by: Liu Song <liu.song13(a)zte.com.cn> --- Changes in v2: - Fixed email formatting to ensure patch applies correctly src/remote/remote_daemon_stream.c | 2 +- src/remote/remote_driver.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 453728a66b..a5032f9a43 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -437,13 +437,13 @@ int daemonAddClientStream(virNetServerClient *client, return -1; } + virObjectRef(client); if (virStreamEventAddCallback(stream->st, 0, daemonStreamEvent, client, virObjectUnref) < 0) return -1; virObjectRef(client); - if ((stream->filterID = virNetServerClientAddFilter(client, daemonStreamFilter, stream)) < 0) { diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 2690c05267..9ac13469e9 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque) { struct remoteStreamCallbackData *cbdata = opaque; - if (!cbdata->cb && cbdata->ff) + if (cbdata->ff) (cbdata->ff)(cbdata->opaque); virObjectUnref(cbdata->st); -- 2.27.0

3 4

[PATCH] qemu_monitor_json: Use proper initializer in qemuMonitorJSONGetBlockInfo()
by Michal Privoznik 25 Jun '25

25 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> Inside of qemuMonitorJSONGetBlockInfo() there's a for loop in which a variable of struct qemuDomainDiskInfo type is declared and initialized as { false }. This works only because stdbool.h declares 'false' as a macro, so preprocessor expands initializer to proper form of { 0 }. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_monitor_json.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index a6fb2a2013..2de68d6518 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2206,7 +2206,7 @@ int qemuMonitorJSONGetBlockInfo(qemuMonitor *mon, for (i = 0; i < virJSONValueArraySize(devices); i++) { virJSONValue *dev; virJSONValue *image; - struct qemuDomainDiskInfo info = { false }; + struct qemuDomainDiskInfo info = { 0 }; const char *thisdev; const char *status; const char *qdev; -- 2.49.0

2 1

[PATCH RFE] conf: Add extraArgs option to passt backend
by Enrique Llorente 25 Jun '25

25 Jun '25

Add support for passing extra arguments to the passt binary through the domain XML configuration. This allows users to specify additional command-line arguments for passt that are not covered by existing structured fields. The new extraArgs attribute is added to the backend element: <backend type='passt' extraArgs='--debug --no-dhcp -v'/> The extraArgs string is parsed using g_shell_parse_argv() to split it into individual arguments before passing them to the passt command. This change includes: - New field in virDomainNetBackend structure - XML schema update to allow extraArgs attribute - Parsing and formatting support in domain_conf.c - Backend comparison function update - Memory cleanup for the new field - QEMU passt integration to use the extra arguments - Comprehensive tests for both user and vhostuser interfaces This is an RFE to gather feedback on the approach. I have a few questions for the community: 1. Is this general approach of adding extraArgs reasonable, or should we instead focus on adding specific structured fields for each passt option? 2. Should extraArgs be marked as unsupported/unstable in the documentation, with a clear indication that it's primarily intended for development and testing purposes? 3. Are there any security concerns with allowing arbitrary arguments to be passed to the passt binary via XML configuration? 4. Would it be better to validate the arguments against a known allowlist rather than allowing any argument string? The current implementation uses g_shell_parse_argv() to safely parse the argument string, but I'm open to feedback on whether additional validation or restrictions should be applied. Signed-off-by: Enrique Llorente <ellorent(a)redhat.com> --- src/conf/domain_conf.c | 6 ++- src/conf/domain_conf.h | 1 + src/conf/schemas/domaincommon.rng | 3 ++ src/qemu/qemu_passt.c | 16 +++++++ ...t-user-passt-extra-args.x86_64-latest.args | 35 ++++++++++++++ ...et-user-passt-extra-args.x86_64-latest.xml | 44 +++++++++++++++++ .../net-user-passt-extra-args.xml | 41 ++++++++++++++++ ...stuser-passt-extra-args.x86_64-latest.args | 36 ++++++++++++++ ...ostuser-passt-extra-args.x86_64-latest.xml | 47 +++++++++++++++++++ .../net-vhostuser-passt-extra-args.xml | 44 +++++++++++++++++ tests/qemuxmlconftest.c | 2 + 11 files changed, 274 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/net-user-passt-extra-args.xml create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.xml diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 1e24e41a48..a83b9002d0 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2918,6 +2918,7 @@ virDomainNetDefFree(virDomainNetDef *def) g_free(def->backend.tap); g_free(def->backend.vhost); g_free(def->backend.logFile); + g_free(def->backend.extraArgs); virDomainNetTeamingInfoFree(def->teaming); g_free(def->virtPortProfile); g_free(def->script); @@ -9798,6 +9799,7 @@ virDomainNetBackendParseXML(xmlNodePtr node, } def->backend.logFile = virXMLPropString(node, "logFile"); + def->backend.extraArgs = virXMLPropString(node, "extraArgs"); if (tap) def->backend.tap = virFileSanitizePath(tap); @@ -20799,7 +20801,8 @@ virDomainNetBackendIsEqual(virDomainNetBackend *src, if (src->type != dst->type || STRNEQ_NULLABLE(src->tap, dst->tap) || STRNEQ_NULLABLE(src->vhost, dst->vhost) || - STRNEQ_NULLABLE(src->logFile, dst->logFile)) { + STRNEQ_NULLABLE(src->logFile, dst->logFile) || + STRNEQ_NULLABLE(src->extraArgs, dst->extraArgs)) { return false; } return true; @@ -24934,6 +24937,7 @@ virDomainNetBackendFormat(virBuffer *buf, virBufferEscapeString(&attrBuf, " tap='%s'", backend->tap); virBufferEscapeString(&attrBuf, " vhost='%s'", backend->vhost); virBufferEscapeString(&attrBuf, " logFile='%s'", backend->logFile); + virBufferEscapeString(&attrBuf, " extraArgs='%s'", backend->extraArgs); virXMLFormatElement(buf, "backend", &attrBuf, NULL); } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 6997cf7c09..d85e6e5c8e 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1076,6 +1076,7 @@ struct _virDomainNetBackend { char *vhost; /* The following are currently only valid/used when backend type='passt' */ char *logFile; /* path to logfile used by passt process */ + char *extraArgs; /* extra arguments to pass to passt process */ }; struct _virDomainNetPortForwardRange { diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng index 183dd5db5e..58946b6873 100644 --- a/src/conf/schemas/domaincommon.rng +++ b/src/conf/schemas/domaincommon.rng @@ -3931,6 +3931,9 @@ <ref name="absFilePath"/> </attribute> </optional> + <optional> + <attribute name="extraArgs"/> + </optional> </element> </optional> <optional> diff --git a/src/qemu/qemu_passt.c b/src/qemu/qemu_passt.c index fcc34de384..47efbc4c80 100644 --- a/src/qemu/qemu_passt.c +++ b/src/qemu/qemu_passt.c @@ -229,6 +229,22 @@ qemuPasstStart(virDomainObj *vm, if (net->backend.logFile) virCommandAddArgList(cmd, "--log-file", net->backend.logFile, NULL); + /* Add extra arguments */ + if (net->backend.extraArgs) { + g_auto(GStrv) extraArgv = NULL; + gint argc = 0; + + if (!g_shell_parse_argv(net->backend.extraArgs, &argc, &extraArgv, NULL)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Failed to parse extraArgs: %1$s"), net->backend.extraArgs); + return -1; + } + + for (gint j = 0; j < argc; j++) { + virCommandAddArg(cmd, extraArgv[j]); + } + } + /* Add IP address info */ for (i = 0; i < net->guestIP.nips; i++) { const virNetDevIPAddr *ip = net->guestIP.ips[i]; diff --git a/tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.args b/tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.args new file mode 100644 index 0000000000..48d2596594 --- /dev/null +++ b/tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.args @@ -0,0 +1,35 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1 \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=QEMUGuest1,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-QEMUGuest1/master-key.aes"}' \ +-machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram,acpi=off \ +-accel tcg \ +-cpu qemu64 \ +-m size=219136k \ +-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":224395264}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","read-only":false}' \ +-device '{"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-1-storage","id":"ide0-0-0","bootindex":1}' \ +-netdev '{"type":"stream","addr":{"type":"unix","path":"/var/run/libvirt/qemu/passt/-1-QEMUGuest1-net0.socket"},"server":false,"reconnect-ms":5000,"id":"hostnet0"}' \ +-device '{"driver":"rtl8139","netdev":"hostnet0","id":"net0","mac":"00:11:22:33:44:55","bus":"pci.0","addr":"0x2"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.xml b/tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.xml new file mode 100644 index 0000000000..e01dc55894 --- /dev/null +++ b/tests/qemuxmlconfdata/net-user-passt-extra-args.x86_64-latest.xml @@ -0,0 +1,44 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>qemu64</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='none'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='user'> + <mac address='00:11:22:33:44:55'/> + <source dev='eth42'/> + <ip address='172.17.2.0' family='ipv4' prefix='24'/> + <model type='rtl8139'/> + <backend type='passt' logFile='/var/log/passt.log' extraArgs='--debug --no-dhcp -v'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxmlconfdata/net-user-passt-extra-args.xml b/tests/qemuxmlconfdata/net-user-passt-extra-args.xml new file mode 100644 index 0000000000..2967331796 --- /dev/null +++ b/tests/qemuxmlconfdata/net-user-passt-extra-args.xml @@ -0,0 +1,41 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='none'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='user'> + <mac address='00:11:22:33:44:55'/> + <source dev='eth42'/> + <ip address='172.17.2.0' family='ipv4' prefix='24'/> + <model type='rtl8139'/> + <backend type='passt' logFile='/var/log/passt.log' extraArgs='--debug --no-dhcp -v'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> \ No newline at end of file diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.args b/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.args new file mode 100644 index 0000000000..939905793d --- /dev/null +++ b/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.args @@ -0,0 +1,36 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1 \ +USER=test \ +LOGNAME=test \ +XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.local/share \ +XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.cache \ +XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-QEMUGuest1/.config \ +/usr/bin/qemu-system-x86_64 \ +-name guest=QEMUGuest1,debug-threads=on \ +-S \ +-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-QEMUGuest1/master-key.aes"}' \ +-machine pc,usb=off,dump-guest-core=off,memory-backend=pc.ram,acpi=off \ +-accel tcg \ +-cpu qemu64 \ +-m size=219136k \ +-object '{"qom-type":"memory-backend-file","id":"pc.ram","mem-path":"/var/lib/libvirt/qemu/ram/-1-QEMUGuest1/pc.ram","share":true,"x-use-canonical-path-for-ramblock-id":false,"size":224395264}' \ +-overcommit mem-lock=off \ +-smp 1,sockets=1,cores=1,threads=1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-display none \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-blockdev '{"driver":"host_device","filename":"/dev/HostVG/QEMUGuest1","node-name":"libvirt-1-storage","read-only":false}' \ +-device '{"driver":"ide-hd","bus":"ide.0","unit":0,"drive":"libvirt-1-storage","id":"ide0-0-0","bootindex":1}' \ +-chardev socket,id=charnet0,path=/var/run/libvirt/qemu/passt/-1-QEMUGuest1-net0.socket,reconnect-ms=5000 \ +-netdev '{"type":"vhost-user","chardev":"charnet0","id":"hostnet0"}' \ +-device '{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"00:11:22:33:44:55","bus":"pci.0","addr":"0x2"}' \ +-audiodev '{"id":"audio1","driver":"none"}' \ +-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ +-msg timestamp=on diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.xml b/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.xml new file mode 100644 index 0000000000..2673c6f6d1 --- /dev/null +++ b/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.x86_64-latest.xml @@ -0,0 +1,47 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <memoryBacking> + <access mode='shared'/> + </memoryBacking> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <cpu mode='custom' match='exact' check='none'> + <model fallback='forbid'>qemu64</model> + </cpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='none'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='vhostuser'> + <mac address='00:11:22:33:44:55'/> + <source dev='eth42'/> + <ip address='172.17.2.0' family='ipv4' prefix='24'/> + <model type='virtio'/> + <backend type='passt' logFile='/var/log/passt.log' extraArgs='--debug --no-dhcp --verbose'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.xml b/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.xml new file mode 100644 index 0000000000..1875e24b5a --- /dev/null +++ b/tests/qemuxmlconfdata/net-vhostuser-passt-extra-args.xml @@ -0,0 +1,44 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <memoryBacking> + <access mode='shared'/> + </memoryBacking> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='x86_64' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu-system-x86_64</emulator> + <disk type='block' device='disk'> + <driver name='qemu' type='raw'/> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0' model='none'/> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <interface type='vhostuser'> + <mac address='00:11:22:33:44:55'/> + <source dev='eth42'/> + <ip address='172.17.2.0' family='ipv4' prefix='24'/> + <model type='virtio'/> + <backend type='passt' logFile='/var/log/passt.log' extraArgs='--debug --no-dhcp --verbose'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </interface> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <audio id='1' type='none'/> + <memballoon model='none'/> + </devices> +</domain> \ No newline at end of file diff --git a/tests/qemuxmlconftest.c b/tests/qemuxmlconftest.c index 6ad4d90934..843d7efadb 100644 --- a/tests/qemuxmlconftest.c +++ b/tests/qemuxmlconftest.c @@ -1799,8 +1799,10 @@ mymain(void) DO_TEST_CAPS_LATEST("net-user-addr"); DO_TEST_CAPS_LATEST("net-user-passt"); DO_TEST_CAPS_VER("net-user-passt", "7.2.0"); + DO_TEST_CAPS_LATEST("net-user-passt-extra-args"); DO_TEST_CAPS_LATEST_PARSE_ERROR("net-user-slirp-portforward"); DO_TEST_CAPS_LATEST("net-vhostuser-passt"); + DO_TEST_CAPS_LATEST("net-vhostuser-passt-extra-args"); DO_TEST_CAPS_LATEST_PARSE_ERROR("net-vhostuser-passt-no-shmem"); DO_TEST_CAPS_LATEST("net-virtio"); DO_TEST_CAPS_LATEST("net-virtio-device"); -- 2.49.0

4 4

[PATCH] remote/stream-event: Fix a memory leak in remoteStreamCallbackFree()
by liu.xuemei1＠zte.com.cn 25 Jun '25

25 Jun '25

From: Liu Song <liu.song13(a)zte.com.cn> The ff callback is never called in remoteStreamCallbackFree() because cbdata->cb can not be NULL. This causes a leak of 'cbdata->opaque'. The leak can be reproduced by attaching and detaching to the console of an VM using `virsh console`. ASAN reports the leak stack as: Direct leak of 288 byte(s) in 1 object(s) allocated from: #0 0x7f6edf6ba0c7 in calloc (/lib64/libasan.so.8+0xba0c7) #1 0x7f6edf5175b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x615b0) #2 0x7f6ede6d0be3 in g_type_create_instance (/lib64/libgobject-2.0.so.0+0x3cbe3) #3 0x7f6ede6b82cf in g_object_new_internal (/lib64/libgobject-2.0.so.0+0x242cf) #4 0x7f6ede6b9877 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x25877) #5 0x7f6ede6ba620 in g_object_new (/lib64/libgobject-2.0.so.0+0x26620) #6 0x7f6edeb78138 in virObjectNew ../src/util/virobject.c:252 #7 0x7f6edeb7a78b in virObjectLockableNew ../src/util/virobject.c:274 #8 0x558251e427e1 in virConsoleNew ../tools/virsh-console.c:369 #9 0x558251e427e1 in virshRunConsole ../tools/virsh-console.c:427 Signed-off-by: Liu Song <liu.song13(a)zte.com.cn> --- src/remote/remote_daemon_stream.c | 2 +- src/remote/remote_driver.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/remote/remote_daemon_stream.c b/src/remote/remote_daemon_stream.c index 453728a66b..a5032f9a43 100644 --- a/src/remote/remote_daemon_stream.c +++ b/src/remote/remote_daemon_stream.c @@ -437,13 +437,13 @@ int daemonAddClientStream(virNetServerClient *client, return -1; } + virObjectRef(client); if (virStreamEventAddCallback(stream->st, 0, daemonStreamEvent, client, virObjectUnref) < 0) return -1; virObjectRef(client); - if ((stream->filterID = virNetServerClientAddFilter(client, daemonStreamFilter, stream)) < 0) { diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 2690c05267..9ac13469e9 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -5336,7 +5336,7 @@ static void remoteStreamCallbackFree(void *opaque) { struct remoteStreamCallbackData *cbdata = opaque; - if (!cbdata->cb && cbdata->ff) + if (cbdata->ff) (cbdata->ff)(cbdata->opaque); virObjectUnref(cbdata->st); -- 2.27.0

1 0

[PATCH v2 00/13] qemu: use 'usb-bot' device to properly emulate USB cdroms
by Peter Krempa 24 Jun '25

24 Jun '25

Version 2 of this series includes changes I've requested in the review and much more that I've learned during adaptation and testing: - 'usb-bot' and 'usb-storage' are not ABI compatible for CDROMs Migrating a guest from 'usb-bot'(with cdrom) to 'usb-storage' results in I/O errors on reads with linux guest. This required adding compatibility layer - exposing the model in -xml and corresponding post-parse and migratable XML config This patchset still tries as much as possible to use the 'usb-bot' device for cdroms to fix the definition - more tests - keeping of 'usb-storage' support - XML config and documentation - cleanup of the code The necessary logic is explained in the patches as comments. Akihiko Odaki (2): qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT qemu: Replace usb-storage with usb-bot Peter Krempa (11): qemuhotplugtest: Use VIR_DOMAIN_DEF_PARSE_ABI_UPDATE for virDomainDeviceDefParse qemuxmlconftest: Test various combinations of config qemusecuritytest: Use 'disk-usb-device' case instead of 'disk-cdrom-bus-other' qemuxmlconftest: Drop 'disk-cdrom-bus-other' qemuxmlconftest: Distribute testing of 'removable' disk property qemuxmlconftest: Invoke "disk-usb-device" case also without QEMU_CAPS_DEVICE_USB_BOT and with ABI_UPDATE conf: introduce usb disk models 'usb-storage' and 'usb-bot' qemu: Fill in model of 'usb' disks to preserve ABI compatibility qemuBuildDeviceAddresDriveProps: Prepare for 'drive' address for usb-bot disks qemu: monitor: Introduce 'qemuMonitorSetUSBDiskAttached' qemuxmlconftest: Prepare for proper testing in 'disk-cdrom-usb-empty' docs/formatdomain.rst | 23 +++- src/conf/domain_conf.c | 2 + src/conf/domain_conf.h | 3 + src/conf/schemas/domaincommon.rng | 2 + src/qemu/qemu_alias.c | 20 ++- src/qemu/qemu_capabilities.c | 7 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 101 ++++++++++++-- src/qemu/qemu_command.h | 5 + src/qemu/qemu_domain.c | 21 +++ src/qemu/qemu_domain_address.c | 2 + src/qemu/qemu_hotplug.c | 18 +++ src/qemu/qemu_monitor.c | 12 ++ src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 20 +++ src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_postparse.c | 49 ++++++- src/qemu/qemu_postparse.h | 4 +- src/qemu/qemu_validate.c | 37 +++++- tests/qemublocktest.c | 13 +- .../caps_10.0.0_aarch64.xml | 1 + .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_s390x.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 + .../caps_6.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 + .../caps_7.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 + .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_aarch64.xml | 1 + .../caps_8.2.0_armv7l.xml | 1 + .../caps_8.2.0_loongarch64.xml | 1 + .../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_riscv64.xml | 1 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_aarch64+hvf.xml | 1 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + tests/qemuhotplugtest.c | 8 +- .../qemuhotplug-base-live+cdrom-usb.xml | 2 +- .../qemuhotplug-base-live+disk-usb.xml | 2 +- tests/qemusecuritytest.c | 2 +- .../disk-cache.x86_64-latest.xml | 2 +- .../qemuxmlconfdata/disk-cdrom-bus-other.xml | 30 ----- ...m-usb-empty.x86_64-latest.abi-update.args} | 4 +- ...om-usb-empty.x86_64-latest.abi-update.xml} | 6 +- .../disk-device-removable.x86_64-latest.args | 40 ------ .../qemuxmlconfdata/disk-device-removable.xml | 32 ----- .../disk-scsi.x86_64-latest.args | 2 +- tests/qemuxmlconfdata/disk-scsi.xml | 2 +- .../disk-usb-device-model.x86_64-latest.args | 48 +++++++ ...> disk-usb-device-model.x86_64-latest.xml} | 46 ++++--- .../qemuxmlconfdata/disk-usb-device-model.xml | 46 +++++++ ...est.QEMU_CAPS_DEVICE_USB_BOT-disabled.args | 59 +++++++++ ...test.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml | 107 +++++++++++++++ ...ate.QEMU_CAPS_DEVICE_USB_BOT-disabled.args | 59 +++++++++ ...date.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml | 125 ++++++++++++++++++ ...k-usb-device.x86_64-latest.abi-update.args | 63 +++++++++ ...sk-usb-device.x86_64-latest.abi-update.xml | 125 ++++++++++++++++++ .../disk-usb-device.x86_64-latest.args | 30 ++++- .../disk-usb-device.x86_64-latest.xml | 82 ++++++++++-- tests/qemuxmlconfdata/disk-usb-device.xml | 66 ++++++++- tests/qemuxmlconftest.c | 16 ++- 75 files changed, 1197 insertions(+), 187 deletions(-) delete mode 100644 tests/qemuxmlconfdata/disk-cdrom-bus-other.xml rename tests/qemuxmlconfdata/{disk-cdrom-bus-other.x86_64-latest.args => disk-cdrom-usb-empty.x86_64-latest.abi-update.args} (84%) rename tests/qemuxmlconfdata/{disk-cdrom-bus-other.x86_64-latest.xml => disk-cdrom-usb-empty.x86_64-latest.abi-update.xml} (89%) delete mode 100644 tests/qemuxmlconfdata/disk-device-removable.x86_64-latest.args delete mode 100644 tests/qemuxmlconfdata/disk-device-removable.xml create mode 100644 tests/qemuxmlconfdata/disk-usb-device-model.x86_64-latest.args rename tests/qemuxmlconfdata/{disk-device-removable.x86_64-latest.xml => disk-usb-device-model.x86_64-latest.xml} (56%) create mode 100644 tests/qemuxmlconfdata/disk-usb-device-model.xml create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.QEMU_CAPS_DEVICE_USB_BOT-disabled.args create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.QEMU_CAPS_DEVICE_USB_BOT-disabled.args create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.QEMU_CAPS_DEVICE_USB_BOT-disabled.xml create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.args create mode 100644 tests/qemuxmlconfdata/disk-usb-device.x86_64-latest.abi-update.xml -- 2.49.0

3 31

[PATCH v2] util: workaround libxml2 lack of thread safe initialization
by Daniel P. Berrangé 23 Jun '25

23 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The main XML parser code global initializer historically had a mutex protecting it, and more recently uses a pthread_once. The RelaxNG code, however, relies on two other global initializers that are not thread safe, just relying on setting an integer "initialized" flag. Calling the relevant initializers from libvirt in a protected global initializer will protect libvirt's own concurrent usage, however, it cannot protect against other libraries loaded in process that might be using libxml2's schema code. Fortunately: * The chances of other loaded non-libvirt code using libxml is relatively low * The chances of other loaded non-libvirt code using the schema validation / catalog functionality inside libxml is even lower * The chances of both libvirt and the non-libvirt usage having their *1st* usage of libxml2 be concurrent is tiny IOW, in practice, although our solution doesn't fully fix the thread safety, it is good enough. libxml2 should none the less still be fixed to make its global initializers be thread safe without special actions by its API consumers[1]. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/788 [1] https://gitlab.gnome.org/GNOME/libxml2/-/merge_requests/326 Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Changed in v3: - Drop xmlInitializeCatalog - I misread the code wrt thread safety - it has a sufficiently protective mutex - Cope with return type change for xmlSchemaInitTypes in libxml >= 2.11.0 src/util/virxml.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/src/util/virxml.c b/src/util/virxml.c index 9d46e5f32f..c851d6f407 100644 --- a/src/util/virxml.c +++ b/src/util/virxml.c @@ -26,6 +26,8 @@ #include <libxml/xmlsave.h> #include <libxml/xpathInternals.h> +#include <libxml/xmlschemastypes.h> +#include <libxml/catalog.h> #include "virerror.h" #include "virxml.h" @@ -35,6 +37,7 @@ #include "virstring.h" #include "virutil.h" #include "viruuid.h" +#include "virthread.h" #include "configmake.h" #define VIR_FROM_THIS VIR_FROM_XML @@ -50,6 +53,28 @@ struct virParserData { }; +static int +virXMLSchemaOnceInit(void) +{ +#if LIBXML_VERSION >= 21100 + if (xmlSchemaInitTypes() < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Unable to initialize libxml2 schema types")); + return -1; + } +#else + xmlSchemaInitTypes(); +#endif + if (xmlRelaxNGInitTypes() < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Unable to initialize libxml2 RelaxNG data")); + return -1; + } + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virXMLSchema); + static xmlXPathContextPtr virXMLXPathContextNew(xmlDocPtr xml) { @@ -1603,6 +1628,9 @@ virXMLValidatorInit(const char *schemafile) { g_autoptr(virXMLValidator) validator = NULL; + if (virXMLSchemaInitialize() < 0) + return NULL; + validator = g_new0(virXMLValidator, 1); validator->schemafile = g_strdup(schemafile); -- 2.49.0

2 1

Re: virsh migrate fails when --copy-storage-all option is given!
by Anushree Mathur 23 Jun '25

23 Jun '25

CC: libvirt devel list Hi Kevin/Peter, Thank you so much for addressing this issue. I tried out few more things and here is my analysis: Even when I removed the readonly option from guest xml I was still seeing the issue in migration,In the qemu-commandline I could still see auto-read-only option being set as true by default. Then I tried giving the auto-read-only as false in the guest xml with qemu-commandline param, it was actually getting set to false and the migration worked! Steps I tried: 1) Started the guest with adding the snippet in the guest xml with parameters as: <qemu:commandline> <qemu:arg value='-blockdev'/> <qemu:arg value='driver=file,filename=/disk_nfs/nfs/migrate_root.qcow2,node-name=drivefile,auto-read-only=false'/> <qemu:arg value='-blockdev'/> <qemu:arg value='driver=qcow2,file=drivefile,node-name=drive0'/> <qemu:arg value='-device'/> <qemu:arg value='virtio-blk-pci,drive=drive0,id=virtio-disk0,bus=pci.0,addr=0x5'/> </qemu:commandline> 2) Started the migration and it worked. Could anyone please clarify from libvirt side what is the change required? Thanks, Anushree-Mathur On 04/06/25 6:57 PM, Peter Krempa wrote: > On Wed, Jun 04, 2025 at 14:41:54 +0200, Kevin Wolf wrote: >> Am 28.05.2025 um 17:34 hat Peter Xu geschrieben: >>> Copy Kevin. >>> >>> On Wed, May 28, 2025 at 07:21:12PM +0530, Anushree Mathur wrote: >>>> Hi all, >>>> >>>> >>>> When I am trying to migrate the guest from host1 to host2 with the command >>>> line as follows: >>>> >>>> date;virsh migrate --live --domain guest1 qemu+ssh://dest/system --verbose >>>> --undefinesource --persistent --auto-converge --postcopy >>>> --copy-storage-all;date >>>> >>>> and it fails with the following error message- >>>> >>>> error: internal error: unable to execute QEMU command 'block-export-add': >>>> Block node is read-only >>>> >>>> HOST ENV: >>>> >>>> qemu : QEMU emulator version 9.2.2 >>>> libvirt : libvirtd (libvirt) 11.1.0 >>>> Seen with upstream qemu also >>>> >>>> Steps to reproduce: >>>> 1) Start the guest1 >>>> 2) Migrate it with the command as >>>> >>>> date;virsh migrate --live --domain guest1 qemu+ssh://dest/system --verbose >>>> --undefinesource --persistent --auto-converge --postcopy >>>> --copy-storage-all;date >>>> >>>> 3) It fails as follows: >>>> error: internal error: unable to execute QEMU command 'block-export-add': >>>> Block node is read-only >> I assume this is about an inactive block node. Probably on the >> destination, but that's not clear to me from the error message. > Yes this would be on the destination. Libvirt exports the nodes on > destination, source connects and does the blockjob. > > The destination side is configured the same way as the source side so > if the source disk is configured as read-write the destination should be > as well > >>>> Things I analyzed- >>>> 1) This issue is not happening if I give --unsafe option in the virsh >>>> migrate command > This is weird; this shouldn't have any impact. > >> What does this translate to on the QEMU command line? >> >>>> 2) O/P of qemu-monitor command also shows ro as false >>>> >>>> virsh qemu-monitor-command guest1 --pretty --cmd '{ "execute": "query-block" > it'd be impossible to execute this on the guest due to timing; you'll > need to collect libvirt debug logs to do that: > > https://www.libvirt.org/kbase/debuglogs.html#tl-dr-enable-debug-logs-for-mo… > > I also thing this should be eventually filed in a > >>>> }' >>>> { >>>> "return": [ >>>> { >>>> "io-status": "ok", >>>> "device": "", >>>> "locked": false, >>>> "removable": false, >>>> "inserted": { >>>> "iops_rd": 0, >>>> "detect_zeroes": "off", >>>> "image": { >>>> "virtual-size": 21474836480, >>>> "filename": "/home/Anu/guest_anu.qcow2", >>>> "cluster-size": 65536, >>>> "format": "qcow2", >>>> "actual-size": 5226561536, >>>> "format-specific": { >>>> "type": "qcow2", >>>> "data": { >>>> "compat": "1.1", >>>> "compression-type": "zlib", >>>> "lazy-refcounts": false, >>>> "refcount-bits": 16, >>>> "corrupt": false, >>>> "extended-l2": false >>>> } >>>> }, >>>> "dirty-flag": false >>>> }, >>>> "iops_wr": 0, >>>> "ro": false, >>>> "node-name": "libvirt-1-format", >>>> "backing_file_depth": 0, >>>> "drv": "qcow2", >>>> "iops": 0, >>>> "bps_wr": 0, >>>> "write_threshold": 0, >>>> "encrypted": false, >>>> "bps": 0, >>>> "bps_rd": 0, >>>> "cache": { >>>> "no-flush": false, >>>> "direct": false, >>>> "writeback": true >>>> }, >>>> "file": "/home/Anu/guest_anu.qcow2" >>>> }, >>>> "qdev": "/machine/peripheral/virtio-disk0/virtio-backend", >>>> "type": "unknown" >>>> } >>>> ], >>>> "id": "libvirt-26" >>>> } >> I assume this is still from the source where the image is still active. > Yes; on the destination the process wouldn't be around long enough to > call 'virsh qemu-monitor-command' > >> Also it doesn't contain the "active" field yet that was recently >> introduced, which could show something about this. I believe you would >> still get "read-only": false for an inactive image if it's supposed to >> be read-write after the migration completes. >> >>>> 3) Guest doesn't have any readonly >>>> >>>> virsh dumpxml guest1 | grep readonly >>>> >>>> 4) Tried giving the proper permissions also >>>> >>>> -rwxrwxrwx. 1 qemu qemu 4.9G Apr 28 15:06 guest_anu.qcow > Is this on the destination? did you pre-create it yourself? otherwise > libvirt is pre-creating that image for-non-shared-storage migration > (--copy-storage-all) which should have proper permissions when it's > created > >>>> 5) Checked for the permission of the pool also that is also proper! >>>> >>>> 6) Found 1 older bug similar to this, pasting the link for reference: >>>> >>>> >>>> https://patchwork.kernel.org/project/qemu-devel/patch/20170811164854.GG4162… >> What's happening in detail is more of a virsh/libvirt question. CCing >> Peter Krempa, he might have an idea. > Please collect the debug log; at least from the destination side of > migration. That should show how the VM is prepared and qemu invoked. >

2 1

[libvirt PATCH v2 REBASED 0/7] qemu: introduce amd-iommu support
by Ján Tomko 23 Jun '25

23 Jun '25

Ján Tomko (7): qemu: introduce QEMU_CAPS_AMD_IOMMU qemu: introduce QEMU_CAPS_PCI_ID qemu: add IOMMU model amd docs: formatdomain: document intel-only IOMMU attributes conf: add passthrough and xtsup attributes for IOMMU conf: reject some attributes not applicable to intel IOMMU qemu: format pt and xstup on the command line docs/formatdomain.rst | 22 +++- src/conf/domain_conf.c | 31 +++++ src/conf/domain_conf.h | 3 + src/conf/domain_validate.c | 22 ++++ src/conf/schemas/domaincommon.rng | 11 ++ src/qemu/qemu_capabilities.c | 12 ++ src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 30 +++++ src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_validate.c | 22 ++++ .../caps_10.0.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.replies | 106 ++++++++++++------ .../caps_10.0.0_x86_64.xml | 2 + .../caps_6.2.0_x86_64.replies | 102 +++++++++++------ .../caps_6.2.0_x86_64.xml | 1 + .../caps_7.0.0_x86_64.replies | 80 +++++++------ .../caps_7.0.0_x86_64.xml | 1 + .../caps_7.1.0_x86_64.replies | 102 +++++++++++------ .../caps_7.1.0_x86_64.xml | 1 + .../caps_7.2.0_x86_64+hvf.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.replies | 80 +++++++------ .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.replies | 102 +++++++++++------ .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.replies | 102 +++++++++++------ .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.replies | 80 +++++++------ .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.replies | 102 +++++++++++------ .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64.xml | 1 + .../amd-iommu.x86_64-latest.args | 35 ++++++ .../amd-iommu.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/amd-iommu.xml | 39 +++++++ tests/qemuxmlconftest.c | 2 + 42 files changed, 1165 insertions(+), 454 deletions(-) create mode 100644 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/amd-iommu.xml -- 2.49.0

2 14

[PATCH] util: workaround libxml2 lack of thread safe initialization
by Daniel P. Berrangé 23 Jun '25

23 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> The main XML parser code global initializer historically had a mutex protecting it, and more recently uses a pthread_once. The RelaxNG code, however, relies on three other global initializers that are not thread safe, just relying on setting an integer "initialized" flag. Calling the relevant initializers from libvirt in a protected global initializer will protect libvirt's own concurrent usage, however, it cannot protect against other libraries loaded in process that might be using libxml2's schema code. Fortunately: * The chances of other loaded non-libvirt code using libxml is relatively low * The chances of other loaded non-libvirt code using the schema validation / catalog functionality inside libxml is even lower * The chances of both libvirt and the non-libvirt usage having their *1st* usage of libxml2 be concurrent is tiny IOW, in practice, although our solution doesn't fully fix the thread safety, it is good enough. libxml2 should none the less still be fixed to make its global initializers be thread safe without special actions by its API consumers. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/788 Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/util/virxml.c | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/src/util/virxml.c b/src/util/virxml.c index 9d46e5f32f..c2d5a109dc 100644 --- a/src/util/virxml.c +++ b/src/util/virxml.c @@ -26,6 +26,8 @@ #include <libxml/xmlsave.h> #include <libxml/xpathInternals.h> +#include <libxml/xmlschemastypes.h> +#include <libxml/catalog.h> #include "virerror.h" #include "virxml.h" @@ -35,6 +37,7 @@ #include "virstring.h" #include "virutil.h" #include "viruuid.h" +#include "virthread.h" #include "configmake.h" #define VIR_FROM_THIS VIR_FROM_XML @@ -50,6 +53,25 @@ struct virParserData { }; +static int virXMLSchemaOnceInit(void) +{ + if (xmlSchemaInitTypes() < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Unable to initialize libxml2 schema types")); + return -1; + } + if (xmlRelaxNGInitTypes() < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Unable to initialize libxml2 RelaxNG data")); + return -1; + } + /* No return value, it just ignores errors :-( */ + xmlInitializeCatalog(); + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virXMLSchema); + static xmlXPathContextPtr virXMLXPathContextNew(xmlDocPtr xml) { @@ -1603,6 +1625,9 @@ virXMLValidatorInit(const char *schemafile) { g_autoptr(virXMLValidator) validator = NULL; + if (virXMLSchemaInitialize() < 0) + return NULL; + validator = g_new0(virXMLValidator, 1); validator->schemafile = g_strdup(schemafile); -- 2.49.0

2 3

[PATCH] NEWS: mention console type in domain capabilities
by Roman Bogorodskiy 20 Jun '25

20 Jun '25

Signed-off-by: Roman Bogorodskiy <bogorodskiy(a)gmail.com> --- NEWS.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 7d7df72a50..184df16547 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -47,6 +47,17 @@ v11.5.0 (unreleased) * **Improvements** + * Include supported console types in domain capabilities + + Domain capabilities now include information about supported console types, such as:: + + <console supported='yes'> + <enum name='type'> + <value>pty</value> + <value>tcp</value> + </enum> + </console> + * **Bug fixes** -- 2.49.0

2 1

[PATCH] qemu: Remove redundant kvm group config in sysusers.d
by fossdd 19 Jun '25

19 Jun '25

It's already defined by default in systemd: https://github.com/systemd/systemd/blob/v257.6/sysusers.d/basic.conf.in#L32 Adding it again here in libvirt-qemu.sysusers.conf causes the following warning by validating it with sd-sysuers: /usr/lib/sysusers.d/libvirt-qemu.conf:1: Conflict with earlier configuration for group 'kvm' in /usr/lib/sysusers.d/basic.conf:32, ignoring line. I don't know if the GID is important, but from simple grepping around it doesn't seem that way. Signed-off-by: fossdd <fossdd(a)pwned.life> --- src/qemu/libvirt-qemu.sysusers.conf | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/libvirt-qemu.sysusers.conf b/src/qemu/libvirt-qemu.sysusers.conf index 3189191e73..05c35f94d8 100644 --- a/src/qemu/libvirt-qemu.sysusers.conf +++ b/src/qemu/libvirt-qemu.sysusers.conf @@ -1,4 +1,3 @@ -g kvm 36 g qemu 107 u qemu 107:qemu "qemu user" - - m qemu kvm -- 2.50.0

1 0

[PATCH 0/2] qemu: prefer GICv3 on TCG ARM VMs
by Heinrich Schuchardt 19 Jun '25

19 Jun '25

Emulating ARM machines with more than 8 CPUs requires GICv3. Currently libvirt defaults to GICv2 on TCG emulated VMs. This due to a deficiency existing in QEMU in 2017. There are no issues running virtual machine with <features> <gic version='3'/> </features> using current QEMU. Heinrich Schuchardt (2): tests: use virt-6.2 for aarch64 TCG qemu: prefer GICv3 on TCG ARM VMs src/qemu/qemu_postparse.c | 14 ------- ...fault-cpu-tcg-virt-4.2.aarch64-latest.args | 36 ---------------- ...efault-cpu-tcg-virt-4.2.aarch64-latest.xml | 42 ------------------- .../aarch64-default-cpu-tcg-virt-4.2.xml | 20 --------- ...fault-cpu-tcg-virt-6.2.aarch64-latest.args | 36 ++++++++++++++++ ...efault-cpu-tcg-virt-6.2.aarch64-latest.xml | 42 +++++++++++++++++++ .../aarch64-default-cpu-tcg-virt-6.2.xml | 20 +++++++++ .../aarch64-gic-none-tcg.aarch64-latest.args | 2 +- .../aarch64-gic-none-tcg.aarch64-latest.xml | 2 +- .../aarch64-pci-serial.aarch64-latest.args | 2 +- .../aarch64-pci-serial.aarch64-latest.xml | 2 +- ...arch64-traditional-pci.aarch64-latest.args | 2 +- ...aarch64-traditional-pci.aarch64-latest.xml | 2 +- ...aarch64-usb-controller.aarch64-latest.args | 2 +- .../aarch64-usb-controller.aarch64-latest.xml | 2 +- .../aarch64-video-default.aarch64-latest.args | 2 +- .../aarch64-video-default.aarch64-latest.xml | 2 +- ...4-video-virtio-gpu-pci.aarch64-latest.args | 2 +- ...64-video-virtio-gpu-pci.aarch64-latest.xml | 2 +- ...ault-models.aarch64-latest.abi-update.args | 2 +- ...fault-models.aarch64-latest.abi-update.xml | 2 +- ...64-virt-default-models.aarch64-latest.args | 2 +- ...h64-virt-default-models.aarch64-latest.xml | 2 +- ...rch64-virt-default-nic.aarch64-latest.args | 2 +- ...arch64-virt-default-nic.aarch64-latest.xml | 2 +- .../aarch64-virt-graphics.aarch64-latest.args | 2 +- .../aarch64-virt-graphics.aarch64-latest.xml | 2 +- ...h64-virt-headless-mmio.aarch64-latest.args | 2 +- ...ch64-virt-headless-mmio.aarch64-latest.xml | 2 +- .../aarch64-virt-headless.aarch64-latest.args | 2 +- .../aarch64-virt-headless.aarch64-latest.xml | 2 +- ...irt-minimal.aarch64-latest.abi-update.args | 2 +- ...virt-minimal.aarch64-latest.abi-update.xml | 2 +- .../aarch64-virt-minimal.aarch64-latest.args | 2 +- .../aarch64-virt-minimal.aarch64-latest.xml | 2 +- .../aarch64-virt-virtio.aarch64-latest.args | 2 +- .../aarch64-virt-virtio.aarch64-latest.xml | 2 +- ...o-pci-manual-addresses.aarch64-latest.args | 2 +- ...io-pci-manual-addresses.aarch64-latest.xml | 2 +- .../balloon-mmio-deflate.aarch64-latest.args | 2 +- .../balloon-mmio-deflate.aarch64-latest.xml | 2 +- .../cpu-topology5.aarch64-latest.args | 2 +- .../cpu-topology5.aarch64-latest.xml | 2 +- ...efi-aarch64.aarch64-latest.abi-update.args | 2 +- ...-efi-aarch64.aarch64-latest.abi-update.xml | 2 +- ...mware-auto-efi-aarch64.aarch64-latest.args | 2 +- ...rmware-auto-efi-aarch64.aarch64-latest.xml | 2 +- ...-loader-raw.aarch64-latest.abi-update.args | 2 +- ...t-loader-raw.aarch64-latest.abi-update.xml | 2 +- ...-efi-format-loader-raw.aarch64-latest.args | 2 +- ...o-efi-format-loader-raw.aarch64-latest.xml | 2 +- ...i-aarch64-legacy-paths.aarch64-latest.args | 2 +- ...fi-aarch64-legacy-paths.aarch64-latest.xml | 2 +- ...anual-efi-acpi-aarch64.aarch64-latest.args | 2 +- ...manual-efi-acpi-aarch64.aarch64-latest.xml | 2 +- ...ual-efi-noacpi-aarch64.aarch64-latest.args | 2 +- ...nual-efi-noacpi-aarch64.aarch64-latest.xml | 2 +- ...l-noefi-noacpi-aarch64.aarch64-latest.args | 2 +- ...al-noefi-noacpi-aarch64.aarch64-latest.xml | 2 +- .../iommu-smmuv3.aarch64-latest.args | 2 +- .../iommu-smmuv3.aarch64-latest.xml | 2 +- ...ch-virt-console-native.aarch64-latest.args | 2 +- ...ach-virt-console-native.aarch64-latest.xml | 2 +- ...ch-virt-console-virtio.aarch64-latest.args | 2 +- ...ach-virt-console-virtio.aarch64-latest.xml | 2 +- ...-serial+console-native.aarch64-latest.args | 2 +- ...t-serial+console-native.aarch64-latest.xml | 2 +- ...ach-virt-serial-compat.aarch64-latest.args | 2 +- ...mach-virt-serial-compat.aarch64-latest.xml | 2 +- ...ach-virt-serial-native.aarch64-latest.args | 2 +- ...mach-virt-serial-native.aarch64-latest.xml | 2 +- .../mach-virt-serial-pci.aarch64-latest.args | 2 +- .../mach-virt-serial-pci.aarch64-latest.xml | 2 +- .../mach-virt-serial-usb.aarch64-latest.args | 2 +- .../mach-virt-serial-usb.aarch64-latest.xml | 2 +- ...e-expander-bus-aarch64.aarch64-latest.args | 2 +- ...ie-expander-bus-aarch64.aarch64-latest.xml | 2 +- .../pcihole64-virt.aarch64-latest.args | 2 +- .../pcihole64-virt.aarch64-latest.xml | 2 +- .../pvpanic-pci-aarch64.aarch64-latest.args | 2 +- .../pvpanic-pci-aarch64.aarch64-latest.xml | 2 +- ...pci-no-address-aarch64.aarch64-latest.args | 2 +- ...-pci-no-address-aarch64.aarch64-latest.xml | 2 +- .../virtio-iommu-aarch64.aarch64-latest.args | 2 +- .../virtio-iommu-aarch64.aarch64-latest.xml | 2 +- tests/qemuxmlconftest.c | 2 +- 86 files changed, 177 insertions(+), 191 deletions(-) delete mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-4.2.aarch64-latest.args delete mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-4.2.aarch64-latest.xml delete mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-4.2.xml create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-6.2.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-6.2.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/aarch64-default-cpu-tcg-virt-6.2.xml -- 2.48.1

1 4

[PATCH] cpu_map: Add more -noTSX x86 CPU models (Sapphire and Granite rapids)
by Hector Cao 18 Jun '25

18 Jun '25

Several Intel CPU models with TSX technology (HLE & RTM features) are affected by the vulnerability TAA[1]. One of the mitigation methods for TAA is to disable TSX support on the host system. For that purpose, in 2021, Intel published a microcode update to disable TSX. Linux kernel also disables TSX globally by default. Even though TSX can be activated via the kernel command line (tsx=on), many Linux distributions stick with this default behavior and have TSX disabled. This makes existing CPU models that have HLE and RTM enabled not correctly detected by libvirt. This commit adds 2 remaining -noTSX models: - SapphireRapids-noTSX - GraniteRapids-noTSX Hopefully, this is the last effort on adding noTSX variants since Granite Rapids should be the last CPU model to have the TSX feature and is consequently affected by TAA. Indeed, SierraForest does not have RTM and HLE enabled. References: [1] TAA, TSX asynchronous Abort: https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.… --- src/cpu_map/index.xml | 2 + src/cpu_map/meson.build | 2 + src/cpu_map/x86_GraniteRapids-noTSX.xml | 197 +++++++++++++++++++++++ src/cpu_map/x86_SapphireRapids-noTSX.xml | 190 ++++++++++++++++++++++ 4 files changed, 391 insertions(+) create mode 100644 src/cpu_map/x86_GraniteRapids-noTSX.xml create mode 100644 src/cpu_map/x86_SapphireRapids-noTSX.xml diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index 87db338cee..03a2c73ba5 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -116,10 +116,12 @@ <include filename='x86_Snowridge-v3.xml'/> <include filename='x86_Snowridge-v4.xml'/> <include filename='x86_SapphireRapids.xml'/> + <include filename='x86_SapphireRapids-noTSX.xml'/> <include filename='x86_SapphireRapids-v1.xml'/> <include filename='x86_SapphireRapids-v2.xml'/> <include filename='x86_SapphireRapids-v3.xml'/> <include filename='x86_GraniteRapids.xml'/> + <include filename='x86_GraniteRapids-noTSX.xml'/> <include filename='x86_GraniteRapids-v1.xml'/> <include filename='x86_GraniteRapids-v2.xml'/> <include filename='x86_SierraForest.xml'/> diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build index dee8441a13..414cad7352 100644 --- a/src/cpu_map/meson.build +++ b/src/cpu_map/meson.build @@ -80,6 +80,7 @@ cpumap_data = [ 'x86_features.xml', 'x86_GraniteRapids-v1.xml', 'x86_GraniteRapids-v2.xml', + 'x86_GraniteRapids-noTSX.xml', 'x86_GraniteRapids.xml', 'x86_Haswell-IBRS.xml', 'x86_Haswell-noTSX-IBRS.xml', @@ -148,6 +149,7 @@ cpumap_data = [ 'x86_SapphireRapids-v1.xml', 'x86_SapphireRapids-v2.xml', 'x86_SapphireRapids-v3.xml', + 'x86_SapphireRapids-noTSX.xml', 'x86_SapphireRapids.xml', 'x86_SierraForest-v1.xml', 'x86_SierraForest.xml', diff --git a/src/cpu_map/x86_GraniteRapids-noTSX.xml b/src/cpu_map/x86_GraniteRapids-noTSX.xml new file mode 100644 index 0000000000..085b012f83 --- /dev/null +++ b/src/cpu_map/x86_GraniteRapids-noTSX.xml @@ -0,0 +1,197 @@ +<cpus> + <model name='GraniteRapids-noTSX'> + <check partial='compat'/> + <decode host='on' guest='off'/> + <signature family='6' model='173'/> + <vendor name='Intel'/> + <feature name='3dnowprefetch'/> + <feature name='abm'/> + <feature name='adx'/> + <feature name='aes'/> + <feature name='amx-bf16'/> + <feature name='amx-fp16'/> + <feature name='amx-int8'/> + <feature name='amx-tile'/> + <feature name='apic'/> + <feature name='arat'/> + <feature name='arch-capabilities'/> + <feature name='avx'/> + <feature name='avx-vnni'/> + <feature name='avx2'/> + <feature name='avx512-bf16'/> + <feature name='avx512-fp16'/> + <feature name='avx512-vpopcntdq'/> + <feature name='avx512bitalg'/> + <feature name='avx512bw'/> + <feature name='avx512cd'/> + <feature name='avx512dq'/> + <feature name='avx512f'/> + <feature name='avx512ifma'/> + <feature name='avx512vbmi'/> + <feature name='avx512vbmi2'/> + <feature name='avx512vl'/> + <feature name='avx512vnni'/> + <feature name='bmi1'/> + <feature name='bmi2'/> + <feature name='bus-lock-detect'/> + <feature name='clflush'/> + <feature name='clflushopt'/> + <feature name='clwb'/> + <feature name='cmov'/> + <feature name='cx16'/> + <feature name='cx8'/> + <feature name='de'/> + <feature name='erms'/> + <feature name='f16c'/> + <feature name='fbsdp-no'/> + <feature name='fma'/> + <feature name='fpu'/> + <feature name='fsgsbase'/> + <feature name='fsrc'/> + <feature name='fsrm'/> + <feature name='fsrs'/> + <feature name='fxsr'/> + <feature name='fzrm'/> + <feature name='gfni'/> + <feature name='ibrs-all'/> + <feature name='invpcid'/> + <feature name='la57'/> + <feature name='lahf_lm'/> + <feature name='lm'/> + <feature name='mca'/> + <feature name='mcdt-no'/> + <feature name='mce'/> + <feature name='mds-no'/> + <feature name='mmx'/> + <feature name='movbe'/> + <feature name='msr'/> + <feature name='mtrr'/> + <feature name='nx'/> + <feature name='pae'/> + <feature name='pat'/> + <feature name='pbrsb-no'/> + <feature name='pcid'/> + <feature name='pclmuldq'/> + <feature name='pdpe1gb'/> + <feature name='pge'/> + <feature name='pku'/> + <feature name='pni'/> + <feature name='popcnt'/> + <feature name='prefetchiti'/> + <feature name='pschange-mc-no'/> + <feature name='psdp-no'/> + <feature name='pse'/> + <feature name='pse36'/> + <feature name='rdctl-no'/> + <feature name='rdpid'/> + <feature name='rdrand'/> + <feature name='rdseed'/> + <feature name='rdtscp'/> + <feature name='sbdr-ssdp-no'/> + <feature name='sep'/> + <feature name='serialize'/> + <feature name='sha-ni'/> + <feature name='skip-l1dfl-vmentry'/> + <feature name='smap'/> + <feature name='smep'/> + <feature name='spec-ctrl'/> + <feature name='ssbd'/> + <feature name='sse'/> + <feature name='sse2'/> + <feature name='sse4.1'/> + <feature name='sse4.2'/> + <feature name='ssse3'/> + <feature name='syscall'/> + <feature name='taa-no'/> + <feature name='tsc'/> + <feature name='tsc-deadline'/> + <feature name='tsx-ldtrk'/> + <feature name='umip'/> + <feature name='vaes'/> + <feature name='vme'/> + <feature name='vmx-activity-hlt'/> + <feature name='vmx-apicv-register'/> + <feature name='vmx-apicv-vid'/> + <feature name='vmx-apicv-x2apic'/> + <feature name='vmx-apicv-xapic'/> + <feature name='vmx-cr3-load-noexit'/> + <feature name='vmx-cr3-store-noexit'/> + <feature name='vmx-cr8-load-exit'/> + <feature name='vmx-cr8-store-exit'/> + <feature name='vmx-desc-exit'/> + <feature name='vmx-entry-ia32e-mode'/> + <feature name='vmx-entry-load-efer'/> + <feature name='vmx-entry-load-pat'/> + <feature name='vmx-entry-load-perf-global-ctrl'/> + <feature name='vmx-entry-noload-debugctl'/> + <feature name='vmx-ept'/> + <feature name='vmx-ept-1gb'/> + <feature name='vmx-ept-2mb'/> + <feature name='vmx-ept-execonly'/> + <feature name='vmx-eptad'/> + <feature name='vmx-eptp-switching'/> + <feature name='vmx-exit-ack-intr'/> + <feature name='vmx-exit-load-efer'/> + <feature name='vmx-exit-load-pat'/> + <feature name='vmx-exit-load-perf-global-ctrl'/> + <feature name='vmx-exit-nosave-debugctl'/> + <feature name='vmx-exit-save-efer'/> + <feature name='vmx-exit-save-pat'/> + <feature name='vmx-exit-save-preemption-timer'/> + <feature name='vmx-flexpriority'/> + <feature name='vmx-hlt-exit'/> + <feature name='vmx-ins-outs'/> + <feature name='vmx-intr-exit'/> + <feature name='vmx-invept'/> + <feature name='vmx-invept-all-context'/> + <feature name='vmx-invept-single-context'/> + <feature name='vmx-invlpg-exit'/> + <feature name='vmx-invpcid-exit'/> + <feature name='vmx-invvpid'/> + <feature name='vmx-invvpid-all-context'/> + <feature name='vmx-invvpid-single-addr'/> + <feature name='vmx-invvpid-single-context-noglobals'/> + <feature name='vmx-io-bitmap'/> + <feature name='vmx-io-exit'/> + <feature name='vmx-monitor-exit'/> + <feature name='vmx-movdr-exit'/> + <feature name='vmx-msr-bitmap'/> + <feature name='vmx-mtf'/> + <feature name='vmx-mwait-exit'/> + <feature name='vmx-nmi-exit'/> + <feature name='vmx-page-walk-4'/> + <feature name='vmx-page-walk-5'/> + <feature name='vmx-pause-exit'/> + <feature name='vmx-pml'/> + <feature name='vmx-posted-intr'/> + <feature name='vmx-preemption-timer'/> + <feature name='vmx-rdpmc-exit'/> + <feature name='vmx-rdrand-exit'/> + <feature name='vmx-rdseed-exit'/> + <feature name='vmx-rdtsc-exit'/> + <feature name='vmx-rdtscp-exit'/> + <feature name='vmx-secondary-ctls'/> + <feature name='vmx-shadow-vmcs'/> + <feature name='vmx-store-lma'/> + <feature name='vmx-true-ctls'/> + <feature name='vmx-tsc-offset'/> + <feature name='vmx-unrestricted-guest'/> + <feature name='vmx-vintr-pending'/> + <feature name='vmx-vmfunc'/> + <feature name='vmx-vmwrite-vmexit-fields'/> + <feature name='vmx-vnmi'/> + <feature name='vmx-vnmi-pending'/> + <feature name='vmx-vpid'/> + <feature name='vmx-wbinvd-exit'/> + <feature name='vmx-xsaves'/> + <feature name='vpclmulqdq'/> + <feature name='wbnoinvd'/> + <feature name='x2apic'/> + <feature name='xfd'/> + <feature name='xgetbv1'/> + <feature name='xsave'/> + <feature name='xsavec'/> + <feature name='xsaveopt'/> + <feature name='xsaves'/> + </model> +</cpus> diff --git a/src/cpu_map/x86_SapphireRapids-noTSX.xml b/src/cpu_map/x86_SapphireRapids-noTSX.xml new file mode 100644 index 0000000000..de56826741 --- /dev/null +++ b/src/cpu_map/x86_SapphireRapids-noTSX.xml @@ -0,0 +1,190 @@ +<cpus> + <model name='SapphireRapids-noTSX'> + <check partial='compat'/> + <decode host='on' guest='off'/> + <signature family='6' model='143'/> + <vendor name='Intel'/> + <feature name='3dnowprefetch'/> + <feature name='abm'/> + <feature name='adx'/> + <feature name='aes'/> + <feature name='amx-bf16'/> + <feature name='amx-int8'/> + <feature name='amx-tile'/> + <feature name='apic'/> + <feature name='arat'/> + <feature name='arch-capabilities'/> + <feature name='avx'/> + <feature name='avx-vnni'/> + <feature name='avx2'/> + <feature name='avx512-bf16'/> + <feature name='avx512-fp16'/> + <feature name='avx512-vpopcntdq'/> + <feature name='avx512bitalg'/> + <feature name='avx512bw'/> + <feature name='avx512cd'/> + <feature name='avx512dq'/> + <feature name='avx512f'/> + <feature name='avx512ifma'/> + <feature name='avx512vbmi'/> + <feature name='avx512vbmi2'/> + <feature name='avx512vl'/> + <feature name='avx512vnni'/> + <feature name='bmi1'/> + <feature name='bmi2'/> + <feature name='bus-lock-detect'/> + <feature name='clflush'/> + <feature name='clflushopt'/> + <feature name='clwb'/> + <feature name='cmov'/> + <feature name='cx16'/> + <feature name='cx8'/> + <feature name='de'/> + <feature name='erms'/> + <feature name='f16c'/> + <feature name='fma'/> + <feature name='fpu'/> + <feature name='fsgsbase'/> + <feature name='fsrc'/> + <feature name='fsrm'/> + <feature name='fsrs'/> + <feature name='fxsr'/> + <feature name='fzrm'/> + <feature name='gfni'/> + <feature name='ibrs-all'/> + <feature name='invpcid'/> + <feature name='la57'/> + <feature name='lahf_lm'/> + <feature name='lm'/> + <feature name='mca'/> + <feature name='mce'/> + <feature name='mds-no'/> + <feature name='mmx'/> + <feature name='movbe'/> + <feature name='msr'/> + <feature name='mtrr'/> + <feature name='nx'/> + <feature name='pae'/> + <feature name='pat'/> + <feature name='pcid'/> + <feature name='pclmuldq'/> + <feature name='pdpe1gb'/> + <feature name='pge'/> + <feature name='pku'/> + <feature name='pni'/> + <feature name='popcnt'/> + <feature name='pschange-mc-no'/> + <feature name='pse'/> + <feature name='pse36'/> + <feature name='rdctl-no'/> + <feature name='rdpid'/> + <feature name='rdrand'/> + <feature name='rdseed'/> + <feature name='rdtscp'/> + <feature name='sep'/> + <feature name='serialize'/> + <feature name='sha-ni'/> + <feature name='skip-l1dfl-vmentry'/> + <feature name='smap'/> + <feature name='smep'/> + <feature name='spec-ctrl'/> + <feature name='ssbd'/> + <feature name='sse'/> + <feature name='sse2'/> + <feature name='sse4.1'/> + <feature name='sse4.2'/> + <feature name='ssse3'/> + <feature name='syscall'/> + <feature name='taa-no'/> + <feature name='tsc'/> + <feature name='tsc-deadline'/> + <feature name='tsx-ldtrk'/> + <feature name='umip'/> + <feature name='vaes'/> + <feature name='vme'/> + <feature name='vmx-activity-hlt' added='yes'/> + <feature name='vmx-apicv-register' added='yes'/> + <feature name='vmx-apicv-vid' added='yes'/> + <feature name='vmx-apicv-x2apic' added='yes'/> + <feature name='vmx-apicv-xapic' added='yes'/> + <feature name='vmx-cr3-load-noexit' added='yes'/> + <feature name='vmx-cr3-store-noexit' added='yes'/> + <feature name='vmx-cr8-load-exit' added='yes'/> + <feature name='vmx-cr8-store-exit' added='yes'/> + <feature name='vmx-desc-exit' added='yes'/> + <feature name='vmx-entry-ia32e-mode' added='yes'/> + <feature name='vmx-entry-load-efer' added='yes'/> + <feature name='vmx-entry-load-pat' added='yes'/> + <feature name='vmx-entry-load-perf-global-ctrl' added='yes'/> + <feature name='vmx-entry-noload-debugctl' added='yes'/> + <feature name='vmx-ept' added='yes'/> + <feature name='vmx-ept-1gb' added='yes'/> + <feature name='vmx-ept-2mb' added='yes'/> + <feature name='vmx-ept-execonly' added='yes'/> + <feature name='vmx-eptad' added='yes'/> + <feature name='vmx-eptp-switching' added='yes'/> + <feature name='vmx-exit-ack-intr' added='yes'/> + <feature name='vmx-exit-load-efer' added='yes'/> + <feature name='vmx-exit-load-pat' added='yes'/> + <feature name='vmx-exit-load-perf-global-ctrl' added='yes'/> + <feature name='vmx-exit-nosave-debugctl' added='yes'/> + <feature name='vmx-exit-save-efer' added='yes'/> + <feature name='vmx-exit-save-pat' added='yes'/> + <feature name='vmx-exit-save-preemption-timer' added='yes'/> + <feature name='vmx-flexpriority' added='yes'/> + <feature name='vmx-hlt-exit' added='yes'/> + <feature name='vmx-ins-outs' added='yes'/> + <feature name='vmx-intr-exit' added='yes'/> + <feature name='vmx-invept' added='yes'/> + <feature name='vmx-invept-all-context' added='yes'/> + <feature name='vmx-invept-single-context' added='yes'/> + <feature name='vmx-invlpg-exit' added='yes'/> + <feature name='vmx-invpcid-exit' added='yes'/> + <feature name='vmx-invvpid' added='yes'/> + <feature name='vmx-invvpid-all-context' added='yes'/> + <feature name='vmx-invvpid-single-addr' added='yes'/> + <feature name='vmx-invvpid-single-context-noglobals' added='yes'/> + <feature name='vmx-io-bitmap' added='yes'/> + <feature name='vmx-io-exit' added='yes'/> + <feature name='vmx-monitor-exit' added='yes'/> + <feature name='vmx-movdr-exit' added='yes'/> + <feature name='vmx-msr-bitmap' added='yes'/> + <feature name='vmx-mtf' added='yes'/> + <feature name='vmx-mwait-exit' added='yes'/> + <feature name='vmx-nmi-exit' added='yes'/> + <feature name='vmx-page-walk-4' added='yes'/> + <feature name='vmx-page-walk-5' added='yes'/> + <feature name='vmx-pause-exit' added='yes'/> + <feature name='vmx-pml' added='yes'/> + <feature name='vmx-posted-intr' added='yes'/> + <feature name='vmx-preemption-timer' added='yes'/> + <feature name='vmx-rdpmc-exit' added='yes'/> + <feature name='vmx-rdrand-exit' added='yes'/> + <feature name='vmx-rdseed-exit' added='yes'/> + <feature name='vmx-rdtsc-exit' added='yes'/> + <feature name='vmx-rdtscp-exit' added='yes'/> + <feature name='vmx-secondary-ctls' added='yes'/> + <feature name='vmx-shadow-vmcs' added='yes'/> + <feature name='vmx-store-lma' added='yes'/> + <feature name='vmx-true-ctls' added='yes'/> + <feature name='vmx-tsc-offset' added='yes'/> + <feature name='vmx-unrestricted-guest' added='yes'/> + <feature name='vmx-vintr-pending' added='yes'/> + <feature name='vmx-vmfunc' added='yes'/> + <feature name='vmx-vmwrite-vmexit-fields' added='yes'/> + <feature name='vmx-vnmi' added='yes'/> + <feature name='vmx-vnmi-pending' added='yes'/> + <feature name='vmx-vpid' added='yes'/> + <feature name='vmx-wbinvd-exit' added='yes'/> + <feature name='vmx-xsaves' added='yes'/> + <feature name='vpclmulqdq'/> + <feature name='wbnoinvd'/> + <feature name='x2apic'/> + <feature name='xfd'/> + <feature name='xgetbv1'/> + <feature name='xsave'/> + <feature name='xsavec'/> + <feature name='xsaveopt'/> + <feature name='xsaves'/> + </model> +</cpus> -- 2.45.2

3 7

[PATCH] security_manager: Don't leak seclabel in virSecurityManagerGenLabel()
by Michal Privoznik 18 Jun '25

18 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> When a domain is being started, seclabels are generated for it. This is handled in virSecurityManagerGenLabel() which can either find pre-existing seclabel in domain def or generate a new one. At any rate, domainGenSecurityLabel() callback is called and if it fails then the seclabel is removed from domain definition using VIR_DELETE_ELEMENT(). While this shrinks down the seclabels array, it does not free individual item. It has to be freed manually. 80 bytes in 2 blocks are definitely lost in loss record 1,359 of 1,876 at 0x484CEF3: calloc (vg_replace_malloc.c:1675) by 0x4F19B29: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8200.5) by 0x49E4953: virSecurityLabelDefNew (virseclabel.c:59) by 0x4BDE0A4: virSecurityManagerGenLabel (security_manager.c:638) by 0xBA029B7: qemuProcessPrepareDomain (qemu_process.c:6760) by 0xBA07DF2: qemuProcessStart (qemu_process.c:8369) by 0xB93DAC0: qemuDomainObjStart (qemu_driver.c:6371) by 0xB93DE08: qemuDomainCreateWithFlags (qemu_driver.c:6420) by 0xB93DE86: qemuDomainCreate (qemu_driver.c:6438) by 0x4CECEA8: virDomainCreate (libvirt-domain.c:7142) Now, you might think this may lead to a double free, because @seclabel is freed under the 'cleanup' label (if @generated is true). But if @generated is true, then just before calling the callback there's VIR_APPEND_ELEMENT() which clears @seclabel out turning the free under 'cleanup' label into a NOP. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/security/security_manager.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/security/security_manager.c b/src/security/security_manager.c index c2460eae37..5fc4eb4872 100644 --- a/src/security/security_manager.c +++ b/src/security/security_manager.c @@ -669,9 +669,14 @@ virSecurityManagerGenLabel(virSecurityManager *mgr, VIR_APPEND_ELEMENT(vm->seclabels, vm->nseclabels, seclabel); if (sec_managers[i]->drv->domainGenSecurityLabel(sec_managers[i], vm) < 0) { + virSecurityLabelDef *tmp = vm->seclabels[vm->nseclabels - 1]; + if (VIR_DELETE_ELEMENT(vm->seclabels, - vm->nseclabels -1, vm->nseclabels) < 0) + vm->nseclabels - 1, vm->nseclabels) < 0) { vm->nseclabels--; + } + + virSecurityLabelDefFree(tmp); goto cleanup; } -- 2.49.0

3 2

Plans for 11.5.0 release (freeze on 2025-06-24)
by Jiri Denemark 18 Jun '25

18 Jun '25

We are getting close to 11.5.0 release of libvirt. To aim for the release on Tuesday 01 Jul I suggest entering the freeze on Tuesday 24 Jun and tagging RC2 on Friday 27 Jun. I hope this works for everyone. Jirka

1 0

[PATCH] virSocketAddrPrefixToNetmask: Prevent undefined behaviour on bitshifts on signed integer
by Peter Krempa 18 Jun '25

18 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Shifting bits into the sign bit is undefined behaviour in C although both gcc and clang handle it as expected. Since the value is used as unsigned convert it to unsigned int. For code readability use 'if' statement instead of a ternary. Closes: https://gitlab.com/libvirt/libvirt/-/issues/785 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/util/virsocketaddr.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/util/virsocketaddr.c b/src/util/virsocketaddr.c index a2e6701670..f53768878e 100644 --- a/src/util/virsocketaddr.c +++ b/src/util/virsocketaddr.c @@ -1144,12 +1144,14 @@ virSocketAddrPrefixToNetmask(unsigned int prefix, netmask->data.stor.ss_family = AF_UNSPEC; /* assume failure */ if (family == AF_INET) { - int ip; + unsigned int ip = 0; if (prefix > 32) return -1; - ip = prefix ? ~((1 << (32 - prefix)) - 1) : 0; + if (prefix > 0) + ip = ~((1U << (32 - prefix)) - 1); + netmask->data.inet4.sin_addr.s_addr = htonl(ip); netmask->data.stor.ss_family = AF_INET; netmask->len = sizeof(struct sockaddr_in); -- 2.49.0

2 1

[PATCH] qemu: Be more forgiving when acquiring QUERY job when formatting domain XML
by Michal Privoznik 18 Jun '25

18 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> In my previous commit of v11.0.0-rc1~115 I've made QEMU driver implementation for virDomainGetXMLDesc() (qemuDomainGetXMLDesc()) acquire QERY job. See its commit message for more info. But this unfortunately broke apps witch fetch domain XML for incoming migration (like virt-manager). The reason is that for incoming migration the VIR_ASYNC_JOB_MIGRATION_IN async job is set, but the mask of allowed synchronous jobs is empty (because QEMU can't talk on monitor really). This makes virDomainObjBeginJob() fail which in turn makes qemuDomainGetXMLDesc() fail too. It makes sense for qemuDomainGetXMLDesc() to acquire the job (e.g. so that it's coherent with another thread that might be in the middle of a MODIFY job). But failure to dump XML may be treated as broken daemon (e.g. virt-manager does so). Therefore, still try to acquire the QUERY job (if job mask permits it) but, do not treat failure as an error. Fixes: 6cc93bf28842526be2fd596a607ebca796b7fb2e Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2369243 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_driver.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b3b0ee66f8..9b583ad7aa 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -6182,6 +6182,7 @@ static char { virQEMUDriver *driver = dom->conn->privateData; virDomainObj *vm; + bool hasJob = false; char *ret = NULL; virCheckFlags(VIR_DOMAIN_XML_COMMON_FLAGS | VIR_DOMAIN_XML_UPDATE_CPU, @@ -6193,8 +6194,10 @@ static char if (virDomainGetXMLDescEnsureACL(dom->conn, vm->def, flags) < 0) goto cleanup; - if (virDomainObjBeginJob(vm, VIR_JOB_QUERY) < 0) - goto cleanup; + if (virDomainNestedJobAllowed(vm->job, VIR_JOB_QUERY) && + virDomainObjBeginJob(vm, VIR_JOB_QUERY) >= 0) { + hasJob = true; + } qemuDomainUpdateCurrentMemorySize(vm); @@ -6210,7 +6213,8 @@ static char ret = qemuDomainFormatXML(driver, vm, flags); - virDomainObjEndJob(vm); + if (hasJob) + virDomainObjEndJob(vm); cleanup: virDomainObjEndAPI(&vm); -- 2.49.0

2 1

[PATCH 0/6] Various fixes and cleanups
by Peter Krempa 17 Jun '25

17 Jun '25

A collection of random one-off fixes for issues where the root cause was analyzed by the reporter and cleanups that I've recently accumulated. Peter Krempa (6): storage_file_probe: Use named initializer for 'struct FileTypeInfo' virQEMUCapsFindBinary: Refactor local variables virshPrintJobProgress: Don't rewrite migration status line on non-terminals storage: parthelper: Use if/else instead of ternary operator storage: disk: Properly handle partition numbers separated by 'p' tlscert: Don't force 'keyEncipherment' for ECDSA and ECDH src/qemu/qemu_capabilities.c | 9 +- src/rpc/virnettlscert.c | 33 +++-- src/storage/parthelper.c | 7 +- src/storage/storage_backend_disk.c | 9 +- src/storage_file/storage_file_probe.c | 174 ++++++++++++++++++-------- tools/virsh-domain.c | 13 +- 6 files changed, 165 insertions(+), 80 deletions(-) -- 2.49.0

4 9

Re: [PATCH v4 00/27] hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines
by Igor Mammedov 17 Jun '25

17 Jun '25

On Thu, 8 May 2025 15:35:23 +0200 Philippe Mathieu-Daudé <philmd(a)linaro.org> wrote: > Since v3: > - Addressed Thomas and Zhao review comments > - Rename fw_cfg_init_mem_[no]dma() helpers > - Remove unused CPU properties > - Remove {multi,linux}boot.bin > - Added R-b tags > > Since v2: > - Addressed Mark review comments and added his R-b tags > > The versioned 'pc' and 'q35' machines up to 2.12 been marked > as deprecated two releases ago, and are older than 6 years, > so according to our support policy we can remove them. > > This series only includes the 2.6 and 2.7 machines removal, > as it is a big enough number of LoC removed. Rest will > follow. CCing libvirt folks series removes some properties that has been used as compat knobs with 2.6/2.7 machine types that are being removed. However libvirt might still use them, please check if being removed properties are safe to remove as is | should be deprecated 1st | should be left alone from an immediate user perspective. > > Based-on: <20250506143905.4961-1-philmd(a)linaro.org> > [...]

5 4

SEO website
by nokores231＠finfave.com 16 Jun '25

16 Jun '25

SEO website brings you the best free porn in incredible quality and variety for your satisfaction. The web is very useful if you are looking for lesbian porn, Asian porn, or beautiful Indian girls. It is a website that has a lot of potentials and that you should visit to enjoy the best porn online. https://www.freebestpost.com/escorts/assortlist-com~2022_02~15

1 0

escorts services
by mahom90637＠nab4.com 16 Jun '25

16 Jun '25

The top rated escort sites allow you to contact the girl that suits your needs. That is to say, you will be able to call the prostitutes that you consider to be the most beautiful, sensual, or simply cheap. https://www.canadaescorts.ca

1 0

[PATCH v4 0/5] Disable Deprecated Features by Default on s390 CPU Models
by Collin Walling 13 Jun '25

13 Jun '25

Changelog v4 - added qemu.conf option to dictate the default behavior for the deprecated_features attribute (Boris) - added qemuxmlactivetests (Boris) - snuck in missing documentation for deprecated_features in formatdomain.rst v3 - added qemu caps check to avoid breaking s390 guests trying to default deprecated_features='off' on QEMU versions that do not support reporting these features 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 introducing a qemu.conf option for disabling deprecated features by default. They may still be disabled for other model types via the respective attribute, or reenabled if desired. The configured behavior may be overridden by explicitly providing the attribute within the guest XML. Boris Fiuczynski (1): tests: new qemuxmlactive tests for s390x Collin Walling (4): docs: domain: document deprecated_features attribute qemu: caps: add virCPUFeaturePolicy param to virQEMUCapsUpdateCPUDeprecatedFeatures qemu: process: refactor deprecated features code qemu: add default_cpu_deprecated_features configuration option docs/formatdomain.rst | 8 ++++ src/qemu/libvirtd_qemu.aug | 3 ++ src/qemu/qemu.conf.in | 14 ++++++ src/qemu/qemu_capabilities.c | 6 +-- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_conf.c | 33 +++++++++++++ src/qemu/qemu_conf.h | 12 +++++ src/qemu/qemu_driver.c | 3 +- src/qemu/qemu_process.c | 46 +++++++++++++++---- src/qemu/test_libvirtd_qemu.aug.in | 1 + ...ated-features-none-active.s390x-latest.xml | 25 ++++++++++ ...ed-features-none-inactive.s390x-latest.xml | 25 ++++++++++ ...cated-features-off-active.s390x-latest.xml | 25 ++++++++++ ...ted-features-off-inactive.s390x-latest.xml | 25 ++++++++++ ...ecated-features-on-active.s390x-latest.xml | 25 ++++++++++ ...ated-features-on-inactive.s390x-latest.xml | 25 ++++++++++ tests/qemuxmlactivetest.c | 11 ++++- ...deprecated-features-none.s390x-latest.args | 32 +++++++++++++ ...-deprecated-features-none.s390x-latest.xml | 25 ++++++++++ .../cpu-model-deprecated-features-none.xml | 15 ++++++ ...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 | 2 + 30 files changed, 426 insertions(+), 22 deletions(-) create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-none-active.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-none-inactive.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-active.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-off-inactive.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-active.s390x-latest.xml create mode 100644 tests/qemuxmlactive2xmldata/cpu-model-deprecated-features-on-inactive.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.args create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.s390x-latest.xml create mode 100644 tests/qemuxmlconfdata/cpu-model-deprecated-features-none.xml 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

[PATCH v3 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober 13 Jun '25

13 Jun '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (3): ch: Add config file support ch: add log level configuration option NEWS: ch: announce log_level config option NEWS.rst | 5 +++++ src/ch/ch.conf | 11 ++++++++++ src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 +++++++++++++++ src/ch/ch_driver.c | 6 +++++ src/ch/ch_monitor.c | 6 +++++ src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++ src/ch/meson.build | 12 ++++++++++ src/ch/test_libvirtd_ch.aug.in | 5 +++++ 9 files changed, 134 insertions(+) create mode 100644 src/ch/ch.conf create mode 100644 src/ch/libvirtd_ch.aug create mode 100644 src/ch/test_libvirtd_ch.aug.in -- 2.49.0

2 4

[PATCH 0/3] qemu: Replace usb-storage with usb-bot
by Akihiko Odaki 12 Jun '25

12 Jun '25

usb-storage is a compound device that automatically creates a USB mass storage device and a SCSI device as its backend. Unfortunately it lacks some configuration options that are usually present with a SCSI device, and cannot represent CD-ROM in particular. Replace usb-storage with usb-bot, which can be combined with a manually created SCSI device. libvirt will configure the SCSI device in a way identical with how QEMU does for usb-storage except that now it respects a configuration option to represent CD-ROM. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/368 Signed-off-by: Akihiko Odaki <akihiko.odaki(a)daynix.com> --- Akihiko Odaki (3): qemu_capabilities: Introduce QEMU_CAPS_DEVICE_USB_BOT qemu: Replace usb-storage with usb-bot qemu_capabilities: Retire QEMU_CAPS_DEVICE_USB_STORAGE src/qemu/qemu_alias.c | 3 +- src/qemu/qemu_capabilities.c | 19 +- src/qemu/qemu_capabilities.h | 3 +- src/qemu/qemu_command.c | 55 +++++- src/qemu/qemu_command.h | 5 + src/qemu/qemu_hotplug.c | 34 +++- src/qemu/qemu_validate.c | 4 +- .../qemucapabilitiesdata/caps_10.0.0_s390x.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 2 +- .../caps_10.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 2 +- .../caps_5.2.0_aarch64.replies | 174 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_ppc64.replies | 178 +++++------------- tests/qemucapabilitiesdata/caps_5.2.0_ppc64.xml | 2 +- .../caps_5.2.0_riscv64.replies | 170 ++++------------- tests/qemucapabilitiesdata/caps_5.2.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_5.2.0_x86_64.replies | 190 +++++-------------- tests/qemucapabilitiesdata/caps_5.2.0_x86_64.xml | 2 +- .../caps_6.0.0_aarch64.replies | 172 ++++------------- tests/qemucapabilitiesdata/caps_6.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.0.0_x86_64.replies | 188 +++++-------------- tests/qemucapabilitiesdata/caps_6.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_6.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.1.0_x86_64.xml | 2 +- .../caps_6.2.0_aarch64.replies | 178 ++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_6.2.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_6.2.0_x86_64.xml | 2 +- .../caps_7.0.0_aarch64+hvf.replies | 182 +++++------------- .../caps_7.0.0_aarch64+hvf.xml | 2 +- .../caps_7.0.0_aarch64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.0.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_ppc64.replies | 182 +++++------------- tests/qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_7.1.0_x86_64.replies | 194 +++++-------------- tests/qemucapabilitiesdata/caps_7.1.0_x86_64.xml | 2 +- tests/qemucapabilitiesdata/caps_7.2.0_ppc.replies | 186 ++++--------------- tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 +- .../caps_7.2.0_x86_64+hvf.replies | 206 +++++---------------- .../qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml | 2 +- .../qemucapabilitiesdata/caps_7.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_7.2.0_x86_64.xml | 2 +- .../caps_8.0.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.0.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_8.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.0.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 2 +- .../caps_8.2.0_aarch64.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_armv7l.replies | 190 ++++--------------- tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 2 +- .../caps_8.2.0_loongarch64.replies | 186 ++++--------------- .../caps_8.2.0_loongarch64.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_8.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.0.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 2 +- .../caps_9.1.0_riscv64.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.1.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_s390x.replies | 182 ++++-------------- tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 +- .../qemucapabilitiesdata/caps_9.2.0_x86_64.replies | 206 +++++---------------- tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 2 +- tests/qemuhotplugtest.c | 8 +- .../qemuxmlconfdata/disk-cache.x86_64-latest.args | 3 +- .../disk-cdrom-bus-other.x86_64-latest.args | 3 +- .../disk-device-removable.x86_64-latest.args | 3 +- .../disk-usb-device.x86_64-latest.args | 3 +- 84 files changed, 1689 insertions(+), 5346 deletions(-) --- base-commit: e5299ddf86121d3c792ca271ffcb54900eb19dc3 change-id: 20250304-bot-5d84aa3a5cfe Best regards, -- Akihiko Odaki <akihiko.odaki(a)daynix.com>

4 11

[PATCH 0/2] esx: Allow specifying different CA bundle for remote connections
by Martin Kletzander 12 Jun '25

12 Jun '25

**El Blurbo aquí** Martin Kletzander (2): esx: Allow specifying different CA bundle for remote connections NEWS: Mention cainfo_path parameter in esx driver NEWS.rst | 5 +++++ docs/drvesx.rst | 16 ++++++++++++++-- src/esx/esx_util.c | 4 ++++ src/esx/esx_util.h | 1 + src/esx/esx_vi.c | 3 +++ 5 files changed, 27 insertions(+), 2 deletions(-) -- 2.49.0

2 6

[PATCH] storage: Implement a simple 'checkPool' method for 'rbd' type pools
by Krisstoffe 12 Jun '25

12 Jun '25

From: Krisstoffe <krisstoffe(a)free.fr> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/448 Signed-off-by: Krisstoffe <krisstoffe(a)free.fr> --- src/storage/storage_backend_rbd.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 038a1a9e34..29d544d349 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -1442,9 +1442,21 @@ virStorageBackendRBDVolWipe(virStoragePoolObj *pool, } +static int +virStorageBackendRBDCheckPool(virStoragePoolObj *pool, + bool *active) +{ + /* Return previous state remembered by the status XML. If the pool is not + * available we will fail to refresh it and end up in the same situation. */ + *active = virStoragePoolObjIsActive(pool); + return 0; +} + + virStorageBackend virStorageBackendRBD = { .type = VIR_STORAGE_POOL_RBD, + .checkPool = virStorageBackendRBDCheckPool, .refreshPool = virStorageBackendRBDRefreshPool, .createVol = virStorageBackendRBDCreateVol, .buildVol = virStorageBackendRBDBuildVol, -- 2.47.1

2 1

[RFC PATCH v4 0/4] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 12 Jun '25

12 Jun '25

Hi, all. This patch adds Arm CCA support to QEMU driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. We are not yet at the stage where we can merge this patch as host Linux/QEMU support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v4: - Changed the target QEMU binary (Linaro's CCA/v8 version with added QMP functionality) - Added the 'armrme' variant to tests/qemucapabilitiesdata/README.rst. - Renamed data files to include '+armrme': - tests/domaincapsdata/qemu_9.2.0-virt.aarch64+armrme.xml - tests/domaincapsdata/qemu_9.2.0.aarch64+armrme.xml - tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.replies - tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.xml - tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args - tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml - Reorganized the commits to ensure the tests pass even with partial application of the patch. [summary] At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. capability info uses QEMU QMP to query QEMU options. The option that exists now is for selecting a hash algorithm. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [Capability example] Execution results of 'virsh domcapability" on QEMU <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] To obtain capability info, it is necessary to support the QEMU QMP command, which QEMU does not yet support. We added a QMP command to retrieve CCA info for test (See "[software version]" below). I need to check qemu_firmware.c to see if my CPU firmware supports CCA. Since it's not implemented yet, I'll wait until a Linux distributor provides me with a JSON file for CCA. We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the virsh create command. [software version] I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… The QEMU used was enhanced with CCA QMP command and found at: https://github.com/Kazuhiro-Abe-fj/linaro_qemu/tree/cca-latest-qmp which is based on Linaro QEMU (cca/latest) https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/latest?ref_type=heads RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… RFC v3: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LLWA… Signed-off-by: Kazuhiro Abe fj1078ii(a)aa.jp.fujitsu.com Akio Kakuno (3): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema Kazuhiro Abe (1): tests: Adds Arm CCA support docs/formatdomain.rst | 43 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 145 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 29 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 98 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_9.2.0-virt.aarch64+armrme.xml | 244 + .../qemu_9.2.0.aarch64+armrme.xml | 244 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_9.2.0_aarch64+armrme.replies | 36754 ++++++++++++++++ .../caps_9.2.0_aarch64+armrme.xml | 540 + ...ch-security-cca.aarch64-latest+armrme.args | 30 + ...nch-security-cca.aarch64-latest+armrme.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 34 files changed, 38398 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_9.2.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_9.2.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.2.0_aarch64+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest+armrme.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.5

1 4

Re: [RFC PATCH v3 4/6] qemucapabilitiestest: Adds Arm CCA support
by Peter Krempa 12 Jun '25

12 Jun '25

On Thu, May 29, 2025 at 05:10:48 +0000, Kazuhiro Abe (Fujitsu) wrote: > > On 5/20/25 17:54, Peter Krempa wrote: > > On Tue, May 20, 2025 at 17:28:26 +0900, Kazuhiro Abe wrote: > > > From: Akio Kakuno <fj3333bs(a)fujitsu.com> > > > > > > - This test was added to check qemu capabilities for Arm > > > CCA support. > > > > IF > > > > > This test was created using the method described in the > > > documentation. > > > > > > Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com> > > > --- > > > .../caps_9.1.0_aarch64.replies | 36222 > > ++++++++++++++++ > > > .../caps_9.1.0_aarch64.xml | 530 + > > > 2 files changed, 36752 insertions(+) > > > create mode 100644 > > > tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml > > > > Note that I'll be commenting only on the capability testing related matter, not the > > rest of the series. > > > > > diff --git a/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > new file mode 100644 > > > index 0000000000..906a21f0c6 > > > --- /dev/null > > > +++ b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies > > > @@ -0,0 +1,36222 @@ > > > +{ > > > + "execute": "qmp_capabilities", > > > + "id": "libvirt-1" > > > +} > > > + > > > +{ > > > + "return": {}, > > > + "id": "libvirt-1" > > > +} > > > + > > > +{ > > > + "execute": "query-version", > > > + "id": "libvirt-2" > > > +} > > > + > > > +{ > > > + "return": { > > > + "qemu": { > > > + "micro": 91, > > > + "minor": 1, > > > + "major": 9 > > > > This is from 9.2.0-rc1. So firstly the file is named wrong, because it was supposed > > to be 'caps_9.2.0_aarch64.replies' instead. > > > > Also except for the currently developed release we require that the .replies files > > are generated from the final release versions and not the RCs or any other > > non-final code. > > > > The libvirt tree already has qemu caps for 9.2.0 and 10.0.0 for aarch64. > > > > What makes these special? > > > > If there's a reason to have specific capabilities please add a 'variant' > > per tests/qemucapabilitiesdata/README.rst > > Thanks for your comment. > > These were generated from a special QEMU version which support ARM CCA based on 9.2. > So as a temporary measure, I will add a variant to the replies file, > and the name will be caps_9.2.0_aarch64+armrme.replies. I'd expect that now that qemu-10.0 is out you'd be targetting at least qemu-10.1 [1] as ... > > Note that, once the patch about Arm CCA support is merged, > we will change the replies file name. ... it's not yet merged as you are saying. [1] We do allow capabilities captured from the currently in development tree but: - they must be based on a commit from official qemu git - you will have to update them to the final version once qemu-N+1 releases. But since it's not merged yet your patch will need to stay RFC. Please make sure thoug to note it in the capabilities patch that it's not the final version yet so that there's no confusion. Your patch looked like it was something which already exists based on the commit message and I didn't read the cover letter because I wasn't too interested in the series itself, I'm just making sure that capabilities dumps are handled properly so that I don't have to deal with it later.

2 1

[PATCH 0/1] [RFC] Live migration support for ch driver
by Stefan Kober 10 Jun '25

10 Jun '25

This change serves as a proof of concept that adds live migration support to the Cloud Hypervisor driver. It is meant to show feasibility and to receive early feedback. I tested the live migration by invoking: virsh -c ch:///session migrate --domain vmName --desturi ch+ssh://dstHost/session --live Opens: * What is required for a minimal viable live migration to be merged? * Job state tracking? (virDomainObjBeginJob, ...) * What should 'virsh domjobinfo' show? * Testing? * Anything else? Stefan Kober (1): Initial CH migrate API src/ch/ch_conf.h | 4 + src/ch/ch_domain.h | 2 + src/ch/ch_driver.c | 362 +++++++++++++++++++++++++++++- src/ch/ch_monitor.c | 156 +++++++++++++ src/ch/ch_monitor.h | 8 + src/ch/ch_process.c | 136 ++++++++++- src/ch/ch_process.h | 6 + src/hypervisor/domain_interface.c | 1 + src/libvirt-domain.c | 15 +- 9 files changed, 680 insertions(+), 10 deletions(-) -- 2.49.0

3 5

[PATCH] docs: fix list term highlighting in URI docs
by Daniel P. Berrangé 10 Jun '25

10 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Having a blank line between the term and its definition prevents the RST to HTML convertor highlighting 'pkipath' correctly. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/uri.rst | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/uri.rst b/docs/uri.rst index 1d2c68f5b8..cc970001f4 100644 --- a/docs/uri.rst +++ b/docs/uri.rst @@ -296,7 +296,6 @@ Supported extra parameters: **Example:** ``no_verify=1`` ``pkipath`` - Specifies x509 certificates path for the client. If any of the CA certificate, client certificate, or client key is missing, the connection will fail with a fatal error. -- 2.49.0

2 1

Question about managed/unmanaged persistent reservation disks
by Annie Li 09 Jun '25

09 Jun '25

Hello, I've been looking at source code related to persistent reservation and got confused a little bit about managed persistent reservation disks. For disk configured with 'managed=yes' as the following, <reservations managed='yes'> <source type='unix' path='/var/lib/libvirt/qemu/domain-7-brml10g19-iscsi-rese/pr-helper0.sock' mode='client'/> </reservations> libvirt is responsible for starting a pr-helper program with a specific associated socket file. The following source code shows that there is only one pr-helper and socket file associated with the managed disks for one VM. const char * qemuDomainGetManagedPRAlias(void) { return "pr-helper0"; } char * qemuDomainGetManagedPRSocketPath(qemuDomainObjPrivate *priv) { return g_strdup_printf("%s/%s.sock", priv->libDir, qemuDomainGetManagedPRAlias()); } So if the VM is booted with multiple disks configured with 'managed=yes' for reservation, I suppose these multiple disks share the this managed pr-helper and socket file. However, per the qemu document, https://www.qemu.org/docs/master/interop/pr-helper.html <https://www.qemu.org/docs/master/interop/pr-helper.html> "It is invalid to send multiple commands concurrently on the same socket. It is however possible to connect multiple sockets to the helper and send multiple commands to the helper for one or more file descriptors." Due to this limitation above, only one persistent reservation disk is allowed as managed in theory. However, libvirt doesn't throw out any error or warning when the VM is booted up with multiple managed persistent reservation disks. I am wondering if I've missed something here? For unmanaged persistent reservation disks, libvirt doesn't start the pr-helper program for them. It is user's responsibility to start this program with customized socket file per disk, but the complexity increases with numbers of persistent reservation disks, especially in the case of hotplug/hotunplog. Is there any plan to support multiple managed persistent reservation disks with separate pr-helper/socket file? Any suggestions/clarifications are greatly appreciated. Thanks Annie

1 0

[PATCH] nvme: Fix more missing enum switches for VIR_DOMAIN_DISK_BUS_NVME
by Martin Kletzander 09 Jun '25

09 Jun '25

From: Martin Kletzander <mkletzan(a)redhat.com> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- So it turned out there were more places, but some even in code that was compiling on my machine and in the CI, but was not found. Not sure why, but I went through all the places again from scratch, hopefully this time that's all. Pushed. src/bhyve/bhyve_domain.c | 1 + src/qemu/qemu_validate.c | 1 + src/vz/vz_sdk.c | 2 ++ src/vz/vz_utils.c | 1 + 4 files changed, 5 insertions(+) diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c index 3e18a462e460..c9bbf27d83ca 100644 --- a/src/bhyve/bhyve_domain.c +++ b/src/bhyve/bhyve_domain.c @@ -143,6 +143,7 @@ bhyveDomainDiskDefAssignAddress(struct _bhyveConn *driver, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: break; diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c index 5eaaca87fed6..b2faf4300204 100644 --- a/src/qemu/qemu_validate.c +++ b/src/qemu/qemu_validate.c @@ -1556,6 +1556,7 @@ qemuValidateDomainDeviceDefAddressDrive(virDomainDeviceInfo *info, case VIR_DOMAIN_DISK_BUS_SD: case VIR_DOMAIN_DISK_BUS_NONE: case VIR_DOMAIN_DISK_BUS_UML: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: break; } diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 684b76ffa057..160778146dcd 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -3380,6 +3380,7 @@ static int prlsdkConfigureDisk(struct _vzDriver *driver, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", @@ -4339,6 +4340,7 @@ prlsdkGetBlockStats(PRL_HANDLE sdkstats, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_INTERNAL_ERROR, diff --git a/src/vz/vz_utils.c b/src/vz/vz_utils.c index 7c08d0f88b58..976303479bb6 100644 --- a/src/vz/vz_utils.c +++ b/src/vz/vz_utils.c @@ -242,6 +242,7 @@ vzCheckDiskAddressDriveUnsupportedParams(virDomainDiskDef *disk) case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", -- 2.49.0

2 1

[PATCH 0/3] Drop unnecessary build dependencies
by Andrea Bolognani 09 Jun '25

09 Jun '25

We've recently stopped checking for the presence of several commands at build time. That means we don't need them in the RPM or CI build environment either. Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/1855622714 Andrea Bolognani (3): rpm: Fix/clarify Requires rpm: Drop unnecessary BuildRequires ci: Drop unnecessary build dependencies ci/buildenv/almalinux-9.sh | 9 --------- ci/buildenv/alpine-321.sh | 6 ------ ci/buildenv/alpine-edge.sh | 6 ------ ci/buildenv/centos-stream-9.sh | 9 --------- ci/buildenv/debian-12-cross-aarch64.sh | 8 -------- ci/buildenv/debian-12-cross-armv6l.sh | 8 -------- ci/buildenv/debian-12-cross-armv7l.sh | 8 -------- ci/buildenv/debian-12-cross-i686.sh | 8 -------- ci/buildenv/debian-12-cross-mips64el.sh | 8 -------- ci/buildenv/debian-12-cross-mipsel.sh | 8 -------- ci/buildenv/debian-12-cross-ppc64le.sh | 8 -------- ci/buildenv/debian-12-cross-s390x.sh | 8 -------- ci/buildenv/debian-12.sh | 8 -------- ci/buildenv/debian-sid-cross-aarch64.sh | 8 -------- ci/buildenv/debian-sid-cross-armv6l.sh | 8 -------- ci/buildenv/debian-sid-cross-armv7l.sh | 8 -------- ci/buildenv/debian-sid-cross-i686.sh | 8 -------- ci/buildenv/debian-sid-cross-mips64el.sh | 8 -------- ci/buildenv/debian-sid-cross-ppc64le.sh | 8 -------- ci/buildenv/debian-sid-cross-s390x.sh | 8 -------- ci/buildenv/debian-sid.sh | 8 -------- ci/buildenv/fedora-41.sh | 9 --------- ci/buildenv/fedora-42-cross-mingw32.sh | 9 --------- ci/buildenv/fedora-42-cross-mingw64.sh | 9 --------- ci/buildenv/fedora-42.sh | 9 --------- ci/buildenv/fedora-rawhide-cross-mingw32.sh | 9 --------- ci/buildenv/fedora-rawhide-cross-mingw64.sh | 9 --------- ci/buildenv/fedora-rawhide.sh | 9 --------- ci/buildenv/opensuse-leap-15.sh | 8 -------- ci/buildenv/opensuse-tumbleweed.sh | 8 -------- ci/buildenv/ubuntu-2204.sh | 8 -------- ci/buildenv/ubuntu-2404.sh | 8 -------- ci/cirrus/freebsd-13.vars | 2 +- ci/cirrus/freebsd-14.vars | 2 +- ci/containers/almalinux-9.Dockerfile | 9 --------- ci/containers/alpine-321.Dockerfile | 6 ------ ci/containers/alpine-edge.Dockerfile | 6 ------ ci/containers/centos-stream-9.Dockerfile | 9 --------- .../debian-12-cross-aarch64.Dockerfile | 8 -------- .../debian-12-cross-armv6l.Dockerfile | 8 -------- .../debian-12-cross-armv7l.Dockerfile | 8 -------- ci/containers/debian-12-cross-i686.Dockerfile | 8 -------- .../debian-12-cross-mips64el.Dockerfile | 8 -------- .../debian-12-cross-mipsel.Dockerfile | 8 -------- .../debian-12-cross-ppc64le.Dockerfile | 8 -------- ci/containers/debian-12-cross-s390x.Dockerfile | 8 -------- ci/containers/debian-12.Dockerfile | 8 -------- .../debian-sid-cross-aarch64.Dockerfile | 8 -------- .../debian-sid-cross-armv6l.Dockerfile | 8 -------- .../debian-sid-cross-armv7l.Dockerfile | 8 -------- ci/containers/debian-sid-cross-i686.Dockerfile | 8 -------- .../debian-sid-cross-mips64el.Dockerfile | 8 -------- .../debian-sid-cross-ppc64le.Dockerfile | 8 -------- .../debian-sid-cross-s390x.Dockerfile | 8 -------- ci/containers/debian-sid.Dockerfile | 8 -------- ci/containers/fedora-41.Dockerfile | 9 --------- .../fedora-42-cross-mingw32.Dockerfile | 9 --------- .../fedora-42-cross-mingw64.Dockerfile | 9 --------- ci/containers/fedora-42.Dockerfile | 9 --------- .../fedora-rawhide-cross-mingw32.Dockerfile | 9 --------- .../fedora-rawhide-cross-mingw64.Dockerfile | 9 --------- ci/containers/fedora-rawhide.Dockerfile | 9 --------- ci/containers/opensuse-leap-15.Dockerfile | 8 -------- ci/containers/opensuse-tumbleweed.Dockerfile | 8 -------- ci/containers/ubuntu-2204.Dockerfile | 8 -------- ci/containers/ubuntu-2404.Dockerfile | 8 -------- ci/lcitool/projects/libvirt.yml | 9 --------- libvirt.spec.in | 18 +++--------------- 68 files changed, 5 insertions(+), 548 deletions(-) -- 2.49.0

2 4

[PATCH] bhyve: Fix build after introduction of emulated NVMe disks
by Martin Kletzander 09 Jun '25

09 Jun '25

From: Martin Kletzander <mkletzan(a)redhat.com> Somehow I missed one switch over disk bus enum. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed under the 'build-breaker' rule. src/bhyve/bhyve_command.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/bhyve/bhyve_command.c b/src/bhyve/bhyve_command.c index 916d699c8030..c82a07c2eb1d 100644 --- a/src/bhyve/bhyve_command.c +++ b/src/bhyve/bhyve_command.c @@ -370,6 +370,7 @@ bhyveBuildDiskArgStr(const virDomainDef *def, case VIR_DOMAIN_DISK_BUS_USB: case VIR_DOMAIN_DISK_BUS_UML: case VIR_DOMAIN_DISK_BUS_SD: + case VIR_DOMAIN_DISK_BUS_NVME: case VIR_DOMAIN_DISK_BUS_LAST: default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", -- 2.49.0

1 0

[PATCH] docs: outline bug expectations wrt automated tools / AI agents
by Daniel P. Berrangé 09 Jun '25

09 Jun '25

From: Daniel P. Berrangé <berrange(a)redhat.com> Bug reports from automated tools and AI agents are time consuming to triage and have poor signal/noise ratio. Set strong expectations for any reporters using such tools, in a (likely doomed) attempt to stem the flow of poor quality reports. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/bugs.rst | 14 ++++++++++++++ docs/securityprocess.rst | 4 ++++ 2 files changed, 18 insertions(+) diff --git a/docs/bugs.rst b/docs/bugs.rst index 5fd1970caf..e12a6c74ec 100644 --- a/docs/bugs.rst +++ b/docs/bugs.rst @@ -76,6 +76,20 @@ Linux Distribution specific bug reports like to have your procedure for filing bugs mentioned here, please mail the libvirt development list. +Use of automated tools / AI agents +---------------------------------- + +If any automated tool / AI agent is used to identify a bug / security +flaw, the following additional expectations apply when filing a report: + +- The tool / agent used **MUST** be clearly declared in the description +- All stated facts **MUST** be validated as correct and free from AI + hallucinations prior to filing +- The problem **MUST** be described against an upstream release that is + no more than 3 months old. +- The problem **SHOULD** be analysed and accompanied with a proposed + patch that can be directly applied to current git + How to file high quality bug reports ------------------------------------ diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst index 075679df74..b7695ddc59 100644 --- a/docs/securityprocess.rst +++ b/docs/securityprocess.rst @@ -27,6 +27,10 @@ and moderated for non-members. As such you will receive an auto-reply indicating the report is held for moderation. Postings by non-members will be approved by a moderator and the reporter copied on any replies. +Refer to the `bug reporting <bugs.html#use-of-automated-tools-ai-agents>`__ +page for the *expectations around the use of automated tools and AI agents*, +**prior** to filing any security report. + Security notices ---------------- -- 2.49.0

3 5

Re: Can you have a brief look? [Was: Support for emulated NVMe disks in VMX and QEMU]
by Martin Kletzander 09 Jun '25

09 Jun '25

[Adding the list to Cc] On Fri, Jun 06, 2025 at 12:19:16PM +0800, Honglei Wang wrote: >Hi Martin, > >Thanks for following up — yes, I saw your previous email and just had a >chance to review the patches. > >The series looks good to me overall, and I’m fine with the Signed-off-by >trailers you added — thanks for including them. > Thank you for the confirmation. >There might be a small detail to look into: I noticed you changed the >parameters of the virIndexToDiskName function, but it seems not all callers >were updated accordingly. This should be caught by CI, though. If I have >any other issues, I’ll reply on the patch mail list. > You are right, I missed the hyperv driver for some reason. I fixed that in the commit which changes the parameters and pushed the series upstream so that it gets to the next release. >Thanks again for your work on this! > >Best regards > Thank you too and have a nice day, Martin

1 0

[PATCH v3 0/2] Fix forward type=hostdev nets for apparmor
by Tim Small 09 Jun '25

09 Jun '25

Fixes a bug whereby apparmor permissions aren't granted to allow a PCI SR-IOV virtual function to be used in a kvm guest when the VF is defined via a forward type='hostdev' network (as per the 'hostdev' option documented here: https://libvirt.org/formatnetwork.html#connectivity ). Downstream bug here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993856 qemu accesses these PCI virtual functions using the vfio API, so no additional permissions to access to the PCI device resources etc. via /sys/devices/pci[...]/resource et al. are necessary. This is a resend with fixed From in body for the patch emails, and change notes in patch emails. Thanks, Tim. Tim Small (2): virt-aa-helper: refactor for readability virt-aa-helper: Allow SR-IOV VF PCI for hostdev networks .../usr.lib.libvirt.virt-aa-helper.in | 4 +++ src/security/virt-aa-helper.c | 28 ++++++++++++++++--- 2 files changed, 28 insertions(+), 4 deletions(-) -- 2.47.2

2 4

[PATCH] qemu.conf: Improve docs for 'dynamic_ownership' option
by Peter Krempa 09 Jun '25

09 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Add a note that the user/group can be overriden or relabelling disabled using per-vm/disk <seclabel> elements instead of disabling it globally. Add a note that read-only image labels are not restored. Closes: https://gitlab.com/libvirt/libvirt/-/issues/512 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu.conf.in | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu.conf.in b/src/qemu/qemu.conf.in index 042bb75b50..221bfa8095 100644 --- a/src/qemu/qemu.conf.in +++ b/src/qemu/qemu.conf.in @@ -513,7 +513,17 @@ # Whether libvirt should dynamically change file ownership # to match the configured user/group above. Defaults to 1. -# Set to 0 to disable file ownership changes. +# +# Notes: +# - Per domain or per disk image user and group can be configured, or +# relabelling disabled using the <seclabel model='dac'> elements in XML: +# +# https://www.libvirt.org/formatdomain.html#security-label +# +# - The user/group of read-only images is not restored as with read-write +# images as they may be shared among more domains. +# +# Set to 0 to disable file ownership changes globally in the qemu driver. #dynamic_ownership = 1 # Whether libvirt should remember and restore the original -- 2.49.0

2 1

[PATCH] nodedev: add nodedev name to mdevctl unsupport msg
by Boris Fiuczynski 09 Jun '25

09 Jun '25

Let's add the nodedev name to improve the error message for the user. Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com> --- src/node_device/node_device_driver.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c index 2c9e749495..de103d1967 100644 --- a/src/node_device/node_device_driver.c +++ b/src/node_device/node_device_driver.c @@ -927,6 +927,7 @@ nodeDeviceGetMdevctlModifySupportCheck(void) static int virMdevctlModify(virNodeDeviceDef *def, + const char *def_name, bool defined, bool live) { @@ -942,8 +943,9 @@ virMdevctlModify(virNodeDeviceDef *def, if (nodeDeviceGetMdevctlModifySupportCheck() < 0) { VIR_WARN("Installed mdevctl version does not support modify with options jsonfile, defined and live"); - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("Unable to modify mediated device: modify unsupported")); + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("Unable to modify mediated device '%1$s': modify unsupported"), + def_name); return -1; } @@ -952,8 +954,8 @@ virMdevctlModify(virNodeDeviceDef *def, if (status != 0) { virReportError(VIR_ERR_INTERNAL_ERROR, - _("Unable to modify mediated device: %1$s"), - MDEVCTL_ERROR(errmsg)); + _("Unable to modify mediated device '%1$s': %2$s"), + def_name, MDEVCTL_ERROR(errmsg)); return -1; } @@ -1608,8 +1610,9 @@ nodeDeviceDefineXML(virConnect *conn, * nodeDeviceDefValidateUpdate() is not required as uuid and * parent are matching if def was found and changing the type in * the persistent config is allowed. */ - VIR_DEBUG("Update node device '%s' with mdevctl", def->name); - modify_failed = (virMdevctlModify(def, true, false) < 0); + virNodeDeviceDef *olddef = virNodeDeviceObjGetDef(persistent_obj); + VIR_DEBUG("Update node device '%s' with mdevctl", olddef->name); + modify_failed = (virMdevctlModify(def, olddef->name, true, false) < 0); virNodeDeviceObjEndAPI(&persistent_obj); if (modify_failed) return NULL; @@ -2357,6 +2360,7 @@ nodeDeviceUpdate(virNodeDevice *device, /* Update now. */ VIR_DEBUG("Update node device '%s' with mdevctl", def->name); if (virMdevctlModify(new_def, + def->name, (flags & VIR_NODE_DEVICE_UPDATE_AFFECT_CONFIG), (flags & VIR_NODE_DEVICE_UPDATE_AFFECT_LIVE)) < 0) { goto cleanup; -- 2.49.0

2 1

[PATCH] ci: refresh with 'lcitool manifest'
by Michal Privoznik 09 Jun '25

09 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> - Replace Alpine 3.21 with 3.22 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Green pipeline: https://gitlab.com/MichalPrivoznik/libvirt/-/pipelines/1860029940 ci/buildenv/{alpine-321.sh => alpine-322.sh} | 0 .../{alpine-321.Dockerfile => alpine-322.Dockerfile} | 2 +- ci/gitlab/builds.yml | 8 ++++---- ci/gitlab/containers.yml | 4 ++-- ci/manifest.yml | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) rename ci/buildenv/{alpine-321.sh => alpine-322.sh} (100%) rename ci/containers/{alpine-321.Dockerfile => alpine-322.Dockerfile} (98%) diff --git a/ci/buildenv/alpine-321.sh b/ci/buildenv/alpine-322.sh similarity index 100% rename from ci/buildenv/alpine-321.sh rename to ci/buildenv/alpine-322.sh diff --git a/ci/containers/alpine-321.Dockerfile b/ci/containers/alpine-322.Dockerfile similarity index 98% rename from ci/containers/alpine-321.Dockerfile rename to ci/containers/alpine-322.Dockerfile index 2351b03653..03db9a3d22 100644 --- a/ci/containers/alpine-321.Dockerfile +++ b/ci/containers/alpine-322.Dockerfile @@ -4,7 +4,7 @@ # # https://gitlab.com/libvirt/libvirt-ci -FROM docker.io/library/alpine:3.21 +FROM docker.io/library/alpine:3.22 RUN apk update && \ apk upgrade && \ diff --git a/ci/gitlab/builds.yml b/ci/gitlab/builds.yml index 5fab2008d8..ae691862c2 100644 --- a/ci/gitlab/builds.yml +++ b/ci/gitlab/builds.yml @@ -33,15 +33,15 @@ x86_64-almalinux-9-clang: TARGET_BASE_IMAGE: docker.io/library/almalinux:9 -x86_64-alpine-321: +x86_64-alpine-322: extends: .native_build_job needs: - - job: x86_64-alpine-321-container + - job: x86_64-alpine-322-container optional: true allow_failure: false variables: - NAME: alpine-321 - TARGET_BASE_IMAGE: docker.io/library/alpine:3.21 + NAME: alpine-322 + TARGET_BASE_IMAGE: docker.io/library/alpine:3.22 x86_64-alpine-edge: diff --git a/ci/gitlab/containers.yml b/ci/gitlab/containers.yml index 05809fbdeb..0650e4781c 100644 --- a/ci/gitlab/containers.yml +++ b/ci/gitlab/containers.yml @@ -14,11 +14,11 @@ x86_64-almalinux-9-container: NAME: almalinux-9 -x86_64-alpine-321-container: +x86_64-alpine-322-container: extends: .container_job allow_failure: false variables: - NAME: alpine-321 + NAME: alpine-322 x86_64-alpine-edge-container: diff --git a/ci/manifest.yml b/ci/manifest.yml index 14bfef25d2..21d570cb00 100644 --- a/ci/manifest.yml +++ b/ci/manifest.yml @@ -19,7 +19,7 @@ targets: RPM: skip CC: clang - alpine-321: x86_64 + alpine-322: x86_64 alpine-edge: jobs: -- 2.49.0

2 1

[PATCH v5 0/3] Fix virtio console port assignment issue
by Aaron M. Brown 09 Jun '25

09 Jun '25

Changelog: --- v5: - Added xml tests to tests/qemuxmlconfdata - Fixed virito -> virtio typo in commit message --- v4: - Update commit messages --- v3: - Added Reviewed-By - Included CI Results Link --- v2: - Split patch into two commits - Added fixes tag --- This libvirt patch series does the following: 1. fixes an issue with virtio console device port auto assignment on vioserial buses 2. updates console port reservation comment and changes the allowZero variable to allowPortZero for clarity 3. Adds tests for virtio console on the vioserial bus Currently in libvirt, a virtio console device cannot be auto assigned a port number greater than zero on a 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/1855918840 Aaron M. Brown (3): qemuxmlconftest: Add console-virtio-vioserial tests virDomainVirtioSerialAddrAssign: Fix virtio console port auto assignment on vioserial bus domain_addr.c: update console port reservation comment and allowZero var to allowPortZero for clarity src/conf/domain_addr.c | 27 +++++--- ...onsole-virtio-vioserial.x86_64-latest.args | 44 +++++++++++++ ...console-virtio-vioserial.x86_64-latest.xml | 63 +++++++++++++++++++ .../console-virtio-vioserial.xml | 48 ++++++++++++++ tests/qemuxmlconftest.c | 1 + 5 files changed, 173 insertions(+), 10 deletions(-) create mode 100644 tests/qemuxmlconfdata/console-virtio-vioserial.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/console-virtio-vioserial.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/console-virtio-vioserial.xml -- 2.39.5 (Apple Git-154)

3 7

[PATCH pushed] virDomainDriverAutoShutdown: Fix printf conversion specifier for 'waitShutdownSecs'
by Peter Krempa 09 Jun '25

09 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> The variable is declared as unsigned int but two places used '%d'. Reported-in: https://issues.redhat.com/browse/RHEL-95721 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Trivial. src/hypervisor/domain_driver.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/hypervisor/domain_driver.c b/src/hypervisor/domain_driver.c index 35966a5a8d..62bbe176ae 100644 --- a/src/hypervisor/domain_driver.c +++ b/src/hypervisor/domain_driver.c @@ -880,9 +880,9 @@ virDomainDriverAutoShutdown(virDomainDriverAutoShutdownConfig *cfg) } timer = g_timer_new(); - virSystemdNotifyStatus("Waiting %d secs for VM shutdown completion", + virSystemdNotifyStatus("Waiting %u secs for VM shutdown completion", cfg->waitShutdownSecs); - VIR_INFO("Waiting %d secs for VM shutdown completion", cfg->waitShutdownSecs); + VIR_INFO("Waiting %u secs for VM shutdown completion", cfg->waitShutdownSecs); while (1) { bool anyRunning = false; for (i = 0; i < numDomains; i++) { -- 2.49.0

1 0

[PATCH v4 0/2] Fix virtio console port assignment issue
by Aaron M. Brown 06 Jun '25

06 Jun '25

Changelog: --- v4: - Update commit messages --- 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/1832324065 Aaron M. Brown (2): virDomainVirtioSerialAddrAssign: Fix virtio console port assignment on vioserial bus domain_addr.c: Update console port reservation comment and allowZero variable for clarity src/conf/domain_addr.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) -- 2.39.5 (Apple Git-154)

4 7

[PATCH 0/3] docs: Small tweaks to downloads page
by Andrea Bolognani 05 Jun '25

05 Jun '25

*** CLICK HERE TO BLURB *** Andrea Bolognani (3): docs: Unify clone instructions docs: Drop mention of read-only git mirrors docs: Add prompt to clone commands docs/downloads.rst | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) -- 2.49.0

2 7

[PATCH 0/2] docs: Fix docs for VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES_ZEROES
by Peter Krempa 05 Jun '25

05 Jun '25

Remove note about needing a pre-cleared image and document need to enable discards to obtain a sparse image. Peter Krempa (2): Revert "docs: Add warning about using a cleared image with VIR_MIGRATE_PARAM_MIGRATE_DISKS_DETECT_ZEROES_ZEROES" docs: Note that zero detection on migration sparsifies image only when discard='unmap' is set docs/manpages/virsh.rst | 7 +++---- include/libvirt/libvirt-domain.h | 12 +++++------- 2 files changed, 8 insertions(+), 11 deletions(-) -- 2.49.0

2 3

[PATCH 0/7] virsh: Fix cleanup in 'event' command and introduce 'await' command
by Peter Krempa 05 Jun '25

05 Jun '25

'virsh await' is a helper/syntax-sugar command which allows you to wait until a domain reaches a certain state. Currently this series implements conditions named 'domain-inactive' and 'guest-agent-available'. Peter Krempa (7): virthread: Register auto cleanup function for virMutex virthread: Add infrastructure for static virCond definitions virsh: cmdEvent: Ensure that event callbacks are unregistered before returning vshCommandRun: Convert to directly return the exit code vsh: Add support for commands with more return values virsh: Introduce 'await' command for waiting until target domain state is reached virsh: await: Introduce 'guest-agent-available' condition docs/manpages/virsh.rst | 30 ++++ src/util/virthread.h | 7 + tools/virsh-domain-event.c | 321 ++++++++++++++++++++++++++++++++++++- tools/virsh.c | 4 +- tools/virt-admin.c | 4 +- tools/vsh.c | 46 ++++-- tools/vsh.h | 3 +- 7 files changed, 398 insertions(+), 17 deletions(-) -- 2.49.0

2 8

[PATCH] libxl_capabilities: Make some functions return void
by Michal Privoznik 05 Jun '25

05 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> Inside of libxlMakeDomainCapabilities() there are some functions called and basically all of them never return anything but zero (indicating success). Yet, they are called in a fashion that suggests otherwise. Turn those functions into void and drop checks for their retvals. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/libxl/libxl_capabilities.c | 43 +++++++++++++--------------------- 1 file changed, 16 insertions(+), 27 deletions(-) diff --git a/src/libxl/libxl_capabilities.c b/src/libxl/libxl_capabilities.c index 6aca4075e7..48f7619cc4 100644 --- a/src/libxl/libxl_capabilities.c +++ b/src/libxl/libxl_capabilities.c @@ -512,7 +512,7 @@ libxlCapsInitGuests(libxl_ctx *ctx, virCaps *caps) return 0; } -static int +static void libxlMakeDomainOSCaps(const char *machine, virDomainCapsOS *os, virFirmware **firmwares, @@ -527,7 +527,7 @@ libxlMakeDomainOSCaps(const char *machine, capsLoader->readonly.report = true; if (STREQ(machine, "xenpv") || STREQ(machine, "xenpvh")) - return 0; + return; capsLoader->supported = VIR_TRISTATE_BOOL_YES; capsLoader->values.values = g_new0(char *, nfirmwares); @@ -542,11 +542,9 @@ libxlMakeDomainOSCaps(const char *machine, VIR_DOMAIN_LOADER_TYPE_PFLASH); VIR_DOMAIN_CAPS_ENUM_SET(capsLoader->readonly, VIR_TRISTATE_BOOL_YES); - - return 0; } -static int +static void libxlMakeDomainDeviceDiskCaps(virDomainCapsDeviceDisk *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -562,11 +560,9 @@ libxlMakeDomainDeviceDiskCaps(virDomainCapsDeviceDisk *dev) VIR_DOMAIN_DISK_BUS_IDE, VIR_DOMAIN_DISK_BUS_SCSI, VIR_DOMAIN_DISK_BUS_XEN); - - return 0; } -static int +static void libxlMakeDomainDeviceGraphicsCaps(virDomainCapsDeviceGraphics *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -576,11 +572,9 @@ libxlMakeDomainDeviceGraphicsCaps(virDomainCapsDeviceGraphics *dev) VIR_DOMAIN_GRAPHICS_TYPE_SDL, VIR_DOMAIN_GRAPHICS_TYPE_VNC, VIR_DOMAIN_GRAPHICS_TYPE_SPICE); - - return 0; } -static int +static void libxlMakeDomainDeviceVideoCaps(virDomainCapsDeviceVideo *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -590,11 +584,9 @@ libxlMakeDomainDeviceVideoCaps(virDomainCapsDeviceVideo *dev) VIR_DOMAIN_VIDEO_TYPE_VGA, VIR_DOMAIN_VIDEO_TYPE_CIRRUS, VIR_DOMAIN_VIDEO_TYPE_XEN); - - return 0; } -static int +static void libxlMakeDomainDeviceHostdevCaps(virDomainCapsDeviceHostdev *dev) { dev->supported = VIR_TRISTATE_BOOL_YES; @@ -625,10 +617,9 @@ libxlMakeDomainDeviceHostdevCaps(virDomainCapsDeviceHostdev *dev) virDomainCapsEnumClear(&dev->pciBackend); VIR_DOMAIN_CAPS_ENUM_SET(dev->pciBackend, VIR_DEVICE_HOSTDEV_PCI_DRIVER_NAME_XEN); - return 0; } -static int +static void libxlMakeDomainDeviceConsoleCaps(virDomainCapsDeviceConsole *console) { console->supported = VIR_TRISTATE_BOOL_YES; @@ -643,8 +634,6 @@ libxlMakeDomainDeviceConsoleCaps(virDomainCapsDeviceConsole *console) VIR_DOMAIN_CHR_TYPE_UDP, VIR_DOMAIN_CHR_TYPE_UNIX, VIR_DOMAIN_CHR_TYPE_VC); - - return 0; } virCaps * @@ -698,15 +687,15 @@ libxlMakeDomainCapabilities(virDomainCaps *domCaps, else domCaps->maxvcpus = PV_MAX_VCPUS; - if (libxlMakeDomainOSCaps(domCaps->machine, os, firmwares, nfirmwares) < 0 || - libxlMakeDomainDeviceDiskCaps(disk) < 0 || - libxlMakeDomainDeviceGraphicsCaps(graphics) < 0 || - libxlMakeDomainDeviceVideoCaps(video) < 0 || - libxlMakeDomainDeviceConsoleCaps(console)) - return -1; - if (STRNEQ(domCaps->machine, "xenpvh") && - libxlMakeDomainDeviceHostdevCaps(hostdev) < 0) - return -1; + libxlMakeDomainOSCaps(domCaps->machine, os, firmwares, nfirmwares); + libxlMakeDomainDeviceDiskCaps(disk); + libxlMakeDomainDeviceGraphicsCaps(graphics); + libxlMakeDomainDeviceVideoCaps(video); + libxlMakeDomainDeviceConsoleCaps(console); + + if (STRNEQ(domCaps->machine, "xenpvh")) { + libxlMakeDomainDeviceHostdevCaps(hostdev); + } domCaps->features[VIR_DOMAIN_CAPS_FEATURE_IOTHREADS] = VIR_TRISTATE_BOOL_NO; domCaps->features[VIR_DOMAIN_CAPS_FEATURE_VMCOREINFO] = VIR_TRISTATE_BOOL_NO; -- 2.49.0

2 1

[PATCH v2 0/4] conf: graphics def and parse refactor
by Kirill Shchetiniuk 04 Jun '25

04 Jun '25

This series refactors the existing parse logic by using the proper utility functions, it also contains some parameters type changes to void unnecessary type convertions. 1. 'VNC' graphics pasing were refactored to use the vitXMLProp* utility functions. 'autoport' and 'websocketGenerated' remain their bool type, as this structure members can be also modified later and not only determined by the initial XML definition. 2. 'RDP' graphics refactored same as VNC graphics, except that 'multiUser' and 'replaceUser' types changed from bool to tristateBool, as parameters are determined only by the initial XML. 3. 'SDL' graphics fullscreen option type changed from bool to tristateBool, to avoid unnecessary type convertions. 4. 'desktop' graphics fullscreen option is removed as it was never used. Kirill Shchetiniuk (4): conf: VNC graphics parse refactor conf: SDL fullscreen option refactor conf: RDP graphics parse refactor conf: desktop graphics remove unused option docs/formatdomain.rst | 5 +- src/conf/domain_conf.c | 125 ++++++++++++++---------------- src/conf/domain_conf.h | 7 +- src/conf/schemas/domaincommon.rng | 5 -- src/qemu/qemu_command.c | 2 +- src/qemu/qemu_process.c | 4 +- src/qemu/qemu_validate.c | 4 +- src/vbox/vbox_common.c | 8 +- 8 files changed, 71 insertions(+), 89 deletions(-) -- 2.49.0

2 6

[PATCH 0/4] conf: graphics def and parse refactor
by Kirill Shchetiniuk 04 Jun '25

04 Jun '25

This series is supposed to refactor the existing parse logic by using the proper utility function and some parameters type change. 1. VNC graphics pasing were refactored to use the vitXMLProp* utility functions. 'autoport' and 'websocketGenerated' remain their bool type, as this structure members can be also modified later and not only determined by the initial XML definition. 2. RDP graphics refactored same as VNC graphics, exept that 'multiUser' and 'replaceUser' types changed from bool to tristate, as parameters determined only by the initial XML. 3. SDL graphics fullscreen option type changed from bool to tristate, to avoid unnecessary type convertions. 4. desktop fullscreen option is removed as it was never used. Kirill Shchetiniuk (4): conf: VNC graphics parse refactor conf: SDL fullscreen option refactor conf: RDP graphics parse refactor conf: desktop graphics remove unused option docs/formatdomain.rst | 5 +- src/conf/domain_conf.c | 125 ++++++++++++++---------------- src/conf/domain_conf.h | 7 +- src/conf/schemas/domaincommon.rng | 5 -- src/qemu/qemu_command.c | 2 +- src/qemu/qemu_process.c | 4 +- src/qemu/qemu_validate.c | 4 +- src/vbox/vbox_common.c | 8 +- 8 files changed, 71 insertions(+), 89 deletions(-) -- 2.49.0

2 6

[PATCH] qemu: command: Don't attempt to set backend MTU for networks which don't use host backend directly
by Peter Krempa 04 Jun '25

04 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Attempting to set MTU for network types which don't actually use the network device on the host results in a failure. The 'mtu' property is also used e.g. for the 'host_mtu' property of e.g. 'virtio-net-pci' which is applied even in vhost-user mode. Use the existing switch which selects devices without a network device backend on the host side and skip setting the MTU. Tested by running 'passt' in vhost-user mode manually: passt -f --vhost-user -s /tmp/vh.sock and the following XML: <interface type="vhostuser"> <mac address="52:54:00:3d:91:97"/> <source type="unix" path="/tmp/vh.sock" mode="client"/> <model type="virtio"/> <mtu size="9999"/> <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/> </interface> The OS in the guest reports MTU 9999. Closes: https://gitlab.com/libvirt/libvirt/-/issues/717 Closes: https://gitlab.com/libvirt/libvirt/-/issues/192 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_command.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index fec48edfc1..edafe1588c 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -8713,6 +8713,7 @@ qemuBuildInterfaceCommandLine(virQEMUDriver *driver, bool requireNicdev = false; g_autoptr(virJSONValue) hostnetprops = NULL; qemuDomainNetworkPrivate *netpriv = QEMU_DOMAIN_NETWORK_PRIVATE(net); + bool setBackendMTU = true; GSList *n; if (qemuDomainValidateActualNetDef(net, qemuCaps) < 0) @@ -8802,6 +8803,7 @@ qemuBuildInterfaceCommandLine(virQEMUDriver *driver, case VIR_DOMAIN_NET_TYPE_NULL: case VIR_DOMAIN_NET_TYPE_VDS: case VIR_DOMAIN_NET_TYPE_LAST: + setBackendMTU = false; /* These types don't use a network device on the host, but * instead use some other type of connection to the emulated * device in the qemu process. @@ -8842,7 +8844,7 @@ qemuBuildInterfaceCommandLine(virQEMUDriver *driver, } } - if (net->mtu && net->managed_tap != VIR_TRISTATE_BOOL_NO && + if (net->mtu && setBackendMTU && net->managed_tap != VIR_TRISTATE_BOOL_NO && virNetDevSetMTU(net->ifname, net->mtu) < 0) goto cleanup; -- 2.49.0

3 2

[PATCH 0/2] Fix build on non-Linux
by Jiri Denemark 03 Jun '25

03 Jun '25

Jiri Denemark (2): util: Avoid statfs in virFileGetExistingParent util: Move virFileGetExistingParent out of ifdef __linux__ src/util/virfile.c | 56 ++++++++++++++++++++++----------------------- tests/virfilemock.c | 28 +++++++++++++++++++++++ 2 files changed, 56 insertions(+), 28 deletions(-) -- 2.49.0

2 4

[PATCH v2 0/2] qemu: Don't accept VIR_DUMP_LIVE flag in qemuDomainCoreDumpWithFormat()
by Michal Privoznik 03 Jun '25

03 Jun '25

This is a v2 of: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/PP7K… Instead of documenting the flag quirks, let's just error out if specified. Michal Prívozník (2): qemu: Don't accept VIR_DUMP_LIVE flag in qemuDomainCoreDumpWithFormat() NEWS: Document removal of support of VIR_DUMP_LIVE flag from QEMU driver NEWS.rst | 7 +++++++ src/qemu/qemu_driver.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) -- 2.49.0

2 4

[PATCH] lib: Document VIR_DUMP_LIVE flag quirk
by Michal Privoznik 03 Jun '25

03 Jun '25

From: Michal Privoznik <mprivozn(a)redhat.com> The virDomainCoreDump() API has VIR_DUMP_LIVE flag which is documented to leave vCPUs running throughout making of the dump of guest memory. Well, this is not the case for QEMU which pauses vCPUs unconditionally (it calls vm_stop() in dump_init()). Document this quirk. And also mention it in 'virsh dump --live' manapage. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/646 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/manpages/virsh.rst | 3 ++- src/libvirt-domain.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 3a00778467..14f22b32c3 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2927,7 +2927,8 @@ dump Dumps the core of a domain to a file for analysis. If *--live* is specified, the domain continues to run until the core -dump is complete, rather than pausing up front. +dump is complete, rather than pausing up front. Although, the hypervisor might +still decide to pause the guest's vCPUs. If *--crash* is specified, the domain is halted with a crashed status, rather than merely left in a paused state. If *--reset* is specified, the domain is reset after successful dump. diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 93e8f5b853..6d1cd2dba1 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -1445,6 +1445,8 @@ virDomainSaveImageDefineXML(virConnectPtr conn, const char *file, * the guest to run; otherwise, the guest is suspended during the dump. * VIR_DUMP_RESET flag forces reset of the guest after dump. * The above three flags are mutually exclusive. + * However, note that even if VIR_DUMP_LIVE flag is specified, the hypervisor + * might temporarily suspend the guest vCPUs anyway. * * Additionally, if @flags includes VIR_DUMP_BYPASS_CACHE, then libvirt * will attempt to bypass the file system cache while creating the file, -- 2.49.0

3 2

[PATCH 00/11] Support for emulated NVMe disks in VMX and QEMU
by Martin Kletzander 02 Jun '25

02 Jun '25

I took the liberty of adjusting Hongwei's QEMU series and made further adjustments so that the common code can be used for reporting NVMe disks from VMX as well. I added SoBs where I thought applicable, but feel free to correct me and/or agree with me. This series fixes https://issues.redhat.com/browse/RHEL-7390 in the middle, but adds more than just that. Martin Kletzander (11): docs, conf, schemas: Add support for NVMe controller util: Add support for parsing nvmeXnY(pZ) strings conf: Add virDomainDeviceFindNvmeController docs, conf, schemas: Add support for NVMe disks vmx: Add support for NVMe disks qemu_capabilities: Add NVMe controller and disk capabilities qemu_capabilities: Add emulated NVMe disk support to domain capabilities qemu: Add support for NVMe controllers qemu: Add support for emulated NVMe disks NEWS: vmx support for NVMe disks NEWS: qemu support for emulated NVMe disks NEWS.rst | 15 +++ docs/formatdomain.rst | 19 +++- src/bhyve/bhyve_command.c | 1 + src/conf/domain_conf.c | 96 ++++++++++++++++- src/conf/domain_conf.h | 10 ++ src/conf/domain_postparse.c | 2 + src/conf/domain_validate.c | 4 +- src/conf/schemas/domaincommon.rng | 22 +++- src/conf/virconftypes.h | 2 + src/hyperv/hyperv_driver.c | 2 + src/libxl/libxl_driver.c | 2 +- src/qemu/qemu_alias.c | 1 + src/qemu/qemu_capabilities.c | 7 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 33 +++++- src/qemu/qemu_domain_address.c | 5 + src/qemu/qemu_hotplug.c | 10 +- src/qemu/qemu_postparse.c | 1 + src/qemu/qemu_validate.c | 65 ++++++++++-- src/test/test_driver.c | 2 + src/util/virutil.c | 94 ++++++++++++++-- src/util/virutil.h | 7 +- src/vbox/vbox_common.c | 4 +- src/vmx/vmx.c | 85 ++++++++++++++- src/vz/vz_sdk.c | 6 +- .../qemu_10.0.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-q35.x86_64.xml | 1 + .../qemu_10.0.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_10.0.0-tcg.x86_64.xml | 1 + .../qemu_10.0.0-virt.aarch64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.ppc64.xml | 1 + tests/domaincapsdata/qemu_10.0.0.s390x.xml | 1 + .../qemu_10.0.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_10.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 1 + .../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 + .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 1 + .../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 + .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 1 + .../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 + .../qemu_7.2.0-hvf.x86_64+hvf.xml | 1 + .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 1 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 1 + .../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 + .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 1 + .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 1 + .../qemu_8.2.0-tcg-virt.loongarch64.xml | 1 + .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 1 + .../qemu_8.2.0-virt.aarch64.xml | 1 + .../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 + .../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 1 + .../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 1 + .../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 1 + .../qemu_9.1.0-tcg-virt.riscv64.xml | 1 + .../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1 + .../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 + .../qemu_9.2.0-hvf.aarch64+hvf.xml | 1 + .../qemu_9.2.0-q35.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 1 + .../qemu_9.2.0-tcg.x86_64+amdsev.xml | 1 + .../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1 + tests/domaincapsdata/qemu_9.2.0.s390x.xml | 1 + .../qemu_9.2.0.x86_64+amdsev.xml | 1 + tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 1 + .../genericxml2xmlindata/controller-nvme.xml | 21 ++++ .../disk-nvme-invalid-serials.xml | 29 +++++ tests/genericxml2xmlindata/disk-nvme.xml | 32 ++++++ tests/genericxml2xmloutdata/disk-nvme.xml | 38 +++++++ tests/genericxml2xmltest.c | 4 + .../caps_10.0.0_aarch64.xml | 2 + .../caps_10.0.0_ppc64.xml | 2 + .../caps_10.0.0_s390x.xml | 2 + .../caps_10.0.0_x86_64+amdsev.xml | 2 + .../caps_10.0.0_x86_64.xml | 2 + .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 2 + .../caps_6.2.0_x86_64.xml | 2 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 2 + .../caps_7.0.0_x86_64.xml | 2 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 2 + .../caps_7.1.0_x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 2 + .../caps_7.2.0_x86_64+hvf.xml | 2 + .../caps_7.2.0_x86_64.xml | 2 + .../caps_8.0.0_x86_64.xml | 2 + .../caps_8.1.0_x86_64.xml | 2 + .../caps_8.2.0_aarch64.xml | 2 + .../caps_8.2.0_armv7l.xml | 2 + .../caps_8.2.0_loongarch64.xml | 2 + .../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 2 + .../caps_8.2.0_x86_64.xml | 2 + .../caps_9.0.0_x86_64.xml | 2 + .../caps_9.1.0_riscv64.xml | 2 + .../qemucapabilitiesdata/caps_9.1.0_s390x.xml | 2 + .../caps_9.1.0_x86_64.xml | 2 + .../caps_9.2.0_aarch64+hvf.xml | 2 + .../qemucapabilitiesdata/caps_9.2.0_s390x.xml | 2 + .../caps_9.2.0_x86_64+amdsev.xml | 2 + .../caps_9.2.0_x86_64.xml | 2 + .../disk-target-nvme.x86_64-latest.args | 39 +++++++ .../disk-target-nvme.x86_64-latest.xml | 53 ++++++++++ tests/qemuxmlconfdata/disk-target-nvme.xml | 32 ++++++ tests/qemuxmlconftest.c | 1 + tests/utiltest.c | 38 ++++--- tests/vmx2xmldata/esx-in-the-wild-15.vmx | 100 ++++++++++++++++++ tests/vmx2xmldata/esx-in-the-wild-15.xml | 45 ++++++++ tests/vmx2xmldata/esx-in-the-wild-16.vmx | 91 ++++++++++++++++ tests/vmx2xmldata/esx-in-the-wild-16.xml | 37 +++++++ tests/vmx2xmltest.c | 2 + 129 files changed, 1128 insertions(+), 49 deletions(-) create mode 100644 tests/genericxml2xmlindata/controller-nvme.xml create mode 100644 tests/genericxml2xmlindata/disk-nvme-invalid-serials.xml create mode 100644 tests/genericxml2xmlindata/disk-nvme.xml create mode 100644 tests/genericxml2xmloutdata/disk-nvme.xml create mode 100644 tests/qemuxmlconfdata/disk-target-nvme.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/disk-target-nvme.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/disk-target-nvme.xml create mode 100644 tests/vmx2xmldata/esx-in-the-wild-15.vmx create mode 100644 tests/vmx2xmldata/esx-in-the-wild-15.xml create mode 100644 tests/vmx2xmldata/esx-in-the-wild-16.vmx create mode 100644 tests/vmx2xmldata/esx-in-the-wild-16.xml -- 2.49.0

2 14

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

02 Jun '25

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

2 1

[PATCH] docs: Change units to 'kiB' from 'kB'/'kilobytes'/'kb'
by Peter Krempa 02 Jun '25

02 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> Use the short unit for kibibytes instead of the confusing or plainly wrong units. Closes: https://gitlab.com/libvirt/libvirt/-/issues/594 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- docs/formatdomain.rst | 4 ++-- docs/formatnetwork.rst | 4 ++-- docs/manpages/virsh.rst | 6 +++--- include/libvirt/libvirt-domain.h | 12 ++++++------ src/libvirt-domain.c | 12 ++++++------ 5 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..82606ef35f 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -1139,7 +1139,7 @@ influence how virtual memory pages are backed by host pages. element is introduced. It has one compulsory attribute ``size`` which specifies which hugepages should be used (especially useful on systems supporting hugepages of different sizes). The default unit for the ``size`` - attribute is kilobytes (multiplier of 1024). If you want to use different + attribute is kiB (multiplier of 1024). If you want to use different unit, use optional ``unit`` attribute. For systems with NUMA, the optional ``nodeset`` attribute may come handy as it ties given guest's NUMA nodes to certain hugepage sizes. From the example snippet, one gigabyte hugepages are @@ -4298,7 +4298,7 @@ attribute are - ``pcie-to-pci-bridge`` ( :since:`since 4.3.0` ) The root controllers (``pci-root`` and ``pcie-root``) have an optional -``pcihole64`` element specifying how big (in kilobytes, or in the unit specified +``pcihole64`` element specifying how big (in kiB, or in the unit specified by ``pcihole64``'s ``unit`` attribute) the 64-bit PCI hole should be. Some guests (like Windows XP or Windows Server 2003) might crash when QEMU and Seabios are recent enough to support 64-bit PCI holes, unless this is disabled diff --git a/docs/formatnetwork.rst b/docs/formatnetwork.rst index 053fe6ad56..6694a145af 100644 --- a/docs/formatnetwork.rst +++ b/docs/formatnetwork.rst @@ -468,10 +468,10 @@ follows, where accepted values for each attribute is an integer number. ``average`` Specifies the desired average bit rate for the interface being shaped (in - kilobytes/second). + kiB/second). ``peak`` Optional attribute which specifies the maximum rate at which the bridge can - send data (in kilobytes/second). Note the limitation of implementation: this + send data (in kiB/second). Note the limitation of implementation: this attribute in the ``outbound`` element is ignored (as Linux ingress filters don't know it yet). ``burst`` diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 3a00778467..895a905b08 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2274,7 +2274,7 @@ If no *--inbound* or *--outbound* is specified, this command will query and show the bandwidth settings. Otherwise, it will set the inbound or outbound bandwidth. *average,peak,burst,floor* is the same as in command *attach-interface*. Values for *average*, *peak* and *floor* -are expressed in kilobytes per second, while *burst* is expressed in kilobytes +are expressed in kiB per second, while *burst* is expressed in kiB in a single burst at *peak* speed as described in the Network XML documentation at `https://libvirt.org/formatnetwork.html#quality-of-service <https://libvirt.org/formatnetwork.html#quality-of-service>`__. @@ -5261,8 +5261,8 @@ interface. At least one from the *average*, *floor* pair must be specified. The other two *peak* and *burst* are optional, so "average,peak", "average,,burst", "average,,,floor", "average" and ",,,floor" are also legal. Values for *average*, *floor* and *peak* -are expressed in kilobytes per second, while *burst* is expressed in -kilobytes in a single burst at *peak* speed as described in the +are expressed in kiB per second, while *burst* is expressed in +kiB in a single burst at *peak* speed as described in the Network XML documentation at `https://libvirt.org/formatnetwork.html#quality-of-service <https://libvirt.org/formatnetwork.html#quality-of-service>`__. diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 9496631bcc..ac5daf7d0c 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -715,9 +715,9 @@ typedef virDomainInterfaceStatsStruct *virDomainInterfaceStatsPtr; * Since: 0.7.5 */ typedef enum { - /* The total amount of data read from swap space (in kB). (Since: 0.7.5) */ + /* The total amount of data read from swap space (in kiB). (Since: 0.7.5) */ VIR_DOMAIN_MEMORY_STAT_SWAP_IN = 0, - /* The total amount of memory written out to swap space (in kB). (Since: 0.7.5) */ + /* The total amount of memory written out to swap space (in kiB). (Since: 0.7.5) */ VIR_DOMAIN_MEMORY_STAT_SWAP_OUT = 1, /* @@ -738,7 +738,7 @@ typedef enum { /* * The amount of memory left completely unused by the system. Memory that * is available but used for reclaimable caches should NOT be reported as - * free. This value is expressed in kB. + * free. This value is expressed in kiB. * * Since: 0.7.5 */ @@ -748,7 +748,7 @@ typedef enum { * The total amount of usable memory as seen by the domain. This value * may be less than the amount of memory assigned to the domain if a * balloon driver is in use or if the guest OS does not initialize all - * assigned pages. This value is expressed in kB. + * assigned pages. This value is expressed in kiB. * * Since: 0.7.5 */ @@ -762,7 +762,7 @@ typedef enum { VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON = 6, /* Resident Set Size of the process running the domain. This value - * is in kB + * is in kiB * * Since: 0.9.10 */ @@ -785,7 +785,7 @@ typedef enum { /* * The amount of memory, that can be quickly reclaimed without - * additional I/O (in kB). Typically these pages are used for caching files + * additional I/O (in kiB). Typically these pages are used for caching files * from disk. * * Since: 4.6.0 diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 93e8f5b853..ca110bdf85 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -6284,27 +6284,27 @@ virDomainGetInterfaceParameters(virDomainPtr domain, * Memory Statistics: * * VIR_DOMAIN_MEMORY_STAT_SWAP_IN: - * The total amount of data read from swap space (in kb). + * The total amount of data read from swap space (in kiB). * VIR_DOMAIN_MEMORY_STAT_SWAP_OUT: - * The total amount of memory written out to swap space (in kb). + * The total amount of memory written out to swap space (in kiB). * VIR_DOMAIN_MEMORY_STAT_MAJOR_FAULT: * The number of page faults that required disk IO to service. * VIR_DOMAIN_MEMORY_STAT_MINOR_FAULT: * The number of page faults serviced without disk IO. * VIR_DOMAIN_MEMORY_STAT_UNUSED: - * The amount of memory which is not being used for any purpose (in kb). + * The amount of memory which is not being used for any purpose (in kiB). * VIR_DOMAIN_MEMORY_STAT_AVAILABLE: - * The total amount of memory available to the domain's OS (in kb). + * The total amount of memory available to the domain's OS (in kiB). * VIR_DOMAIN_MEMORY_STAT_USABLE: * How much the balloon can be inflated without pushing the guest system * to swap, corresponds to 'Available' in /proc/meminfo * VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON: - * Current balloon value (in kb). + * Current balloon value (in kiB). * VIR_DOMAIN_MEMORY_STAT_LAST_UPDATE * Timestamp of the last statistic * VIR_DOMAIN_MEMORY_STAT_DISK_CACHES * Memory that can be reclaimed without additional I/O, typically disk - * caches (in kb). + * caches (in kiB). * VIR_DOMAIN_MEMORY_STAT_HUGETLB_PGALLOC * The number of successful huge page allocations from inside the domain * VIR_DOMAIN_MEMORY_STAT_HUGETLB_PGFAIL -- 2.49.0

2 1

[PATCH] esx: Avoid corner case where esxUtil_ParseDatastorePath could be called with NULL 'datastorePath'
by Peter Krempa 02 Jun '25

02 Jun '25

From: Peter Krempa <pkrempa(a)redhat.com> The generated code which parses the data from XML in esxVI_LookupDatastoreContentByDatastoreName can fill the 'folderPath' property with NULL if it were missing from the input XML. While this is not likely when talking to esx it is a possible outcome. Skipp NULL results. All other code paths already ensure that the function is not called with NULL. Closes: https://gitlab.com/libvirt/libvirt/-/issues/776 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/esx/esx_storage_backend_vmfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/esx/esx_storage_backend_vmfs.c b/src/esx/esx_storage_backend_vmfs.c index 145aff0c9c..8e13201fe2 100644 --- a/src/esx/esx_storage_backend_vmfs.c +++ b/src/esx/esx_storage_backend_vmfs.c @@ -616,6 +616,9 @@ esxStoragePoolListVolumes(virStoragePoolPtr pool, char **const names, searchResults = searchResults->_next) { g_autofree char *directoryAndFileName = NULL; + if (!searchResults->folderPath) + continue; + if (esxUtil_ParseDatastorePath(searchResults->folderPath, NULL, NULL, &directoryAndFileName) < 0) { goto cleanup; @@ -759,6 +762,9 @@ esxStorageVolLookupByKey(virConnectPtr conn, const char *key) searchResults = searchResults->_next) { g_autofree char *directoryAndFileName = NULL; + if (searchResults->folderPath) + continue; + if (esxUtil_ParseDatastorePath(searchResults->folderPath, NULL, NULL, &directoryAndFileName) < 0) { goto cleanup; -- 2.49.0

2 1

Release of libvirt-11.4.0
by Jiri Denemark 02 Jun '25

02 Jun '25

The 11.4.0 release of both libvirt and libvirt-python is tagged and signed tarballs are available at https://download.libvirt.org/ https://download.libvirt.org/python/ Thanks everybody who helped with this release by sending patches, reviewing, testing, or providing feedback. Your work is greatly appreciated. * New features * qemu: ppc64 POWER11 processor support Support for the recently released IBM POWER11 processor was added. * Packaging changes * All helper programs are now detected from ``$PATH`` during runtime All of the code was now converted to dynamically look up helper programs in ``$PATH`` rather than doing the lookup at build time and then compiling in the result. Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``, ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``, ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``, ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not needed during build and will still work properly if placed in ``$PATH``. This also ensures that libvirt works correctly on distros that are transitioning ``/sbin`` into ``/bin`` and upgraded installations have a different layout from fresh installations. * Improvements * virsh: Add option ``--no-pkttyagent`` 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> * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML The data is now based on the presence of the controller in qemu rather than just a denylist of machine types where floppies not work. * Bug fixes * qemu: Fix failure when reverting to internal snapshots A regression in ``libvirt-11.2`` and ``libvirt-11.3`` prevents reverting to an internal snapshot. Attempts to revert would produce the following error:: error: operation failed: load of internal snapshot 'foo1' job failed: Device 'libvirt-1-format' is writable but does not support snapshots The only workaround is to avoid the broken versions. * qemu: Fix virtqemud crash when resuming failed post-copy migration A regression introduced in ``libvirt-11.2.0`` caused virtqemud on the destination host to crash when trying to resume failed post-copy migration. * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI The queue count itself isn't a device frontend property but libvirt uses it to calculate ``vectors`` option of the device which is a guest OS visible property, thus ``queues`` must not change during migration. The ABI stability check now handles this properly. Enjoy. Jirka

1 0

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

31 May '25

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

3 19

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

30 May '25

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

2 8

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

30 May '25

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

2 1

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

30 May '25

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

1 1

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

29 May '25

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

2 1

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

29 May '25

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

2 2

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

29 May '25

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

2 4

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

29 May '25

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

2 20

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

29 May '25

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

1 3

[RFC PATCH v3 0/6] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 29 May '25

29 May '25

Hi, all. This patch adds Arm CCA support to QEMU driver for aarch64 system. CCA is an abbreviation for Arm Confidential Compute Architecture feature, it enhances the virtualization capabilities of the platform by separating the management of resources from access to those resources. We are not yet at the stage where we can merge this patch as host Linux/QEMU support is not yet merged, but I would like to receive reviews and comments on the overall direction. Changes in v3: Supports two launch VM options: personalization-value and measurement-log. The measurement-log was added to allow us to check if the data loaded into the guest RAM is a good image. The Realm Personalization Value (RPV) was added to allow us to distinguish between realms that have the same initial measurement results. This was added as a new Realm startup option in Linaro QEMU after the v2 patch was posted. That's why we made this change. [summary] At this stage, all you can do is getting the CCA capability with the virsh domcapabilities command and start the CCA VM with the virsh create command. capability info uses QEMU QMP to query QEMU options. The option that exists now is for selecting a hash algorithm. QEMU QMP sections currently only contains a single member, but is wrapped in sections for expansion. [Capability example] Execution results of 'virsh domcapability" on QEMU <domaincapabilities> ... <features> ... </sgx> <cca supported='yes'> <enum name='measurement-algo'> <value>sha256</value> <value>sha512</value> </enum> </cca> <hyperv supported='yes'> ... </features> </domaincapabilities> [XML example] <domain> ... <launchsecurity type='cca'> <measurement-algo>sha256</measurement-algo> </launchsecurity> ... </domain> [limitations/tests] To obtain capability info, it is necessary to support the QEMU QMP command, which QEMU does not yet support. We added a QMP command to retrieve CCA info for test (See "[software version]" below). I need to check qemu_firmware.c to see if my CPU firmware supports CCA. Since it's not implemented yet, I'll wait until a Linux distributor provides me with a JSON file for CCA. We have confirmed that the added tests (qemucapabilitiestest, domaincapstest and qemuxmlconftest) and the CCA VM startup test (starting the CCA VM from the virsh create command) passed. The "personalization-value" and "measurement-log" parameters that exist in the current Linaro QEMU cca/latest branch will not be specified as CCA VM startup parameters with the virsh create command. [software version] I followed the steps in Linaro's blog below. https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+an… The QEMU used was enhanced with CCA QMP command and found at: https://github.com/Kazuhiro-Abe-fj/linaro_qemu/tree/cca-latest-qmp which is based on Linaro QEMU (cca/latest) https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/latest?ref_type=heads RFC v1: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4S5… RFC v2: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5VZ… Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com> Akio Kakuno (6): src: Add ARM CCA support in qemu driver to launch VM src: Add ARM CCA support in domain capabilities command src: Add ARM CCA support in domain schema qemucapabilitiestest: Adds Arm CCA support domaincapstest: Adds Arm CCA support qemuxmlconftest: Adds Arm CCA support docs/formatdomain.rst | 43 + docs/formatdomaincaps.rst | 27 +- src/conf/domain_capabilities.c | 48 + src/conf/domain_capabilities.h | 12 + src/conf/domain_conf.c | 25 + src/conf/domain_conf.h | 9 + src/conf/domain_validate.c | 1 + src/conf/schemas/domaincaps.rng | 36 + src/conf/schemas/domaincommon.rng | 26 + src/conf/virconftypes.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 145 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 29 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 1 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 98 + src/qemu/qemu_monitor_json.h | 4 + src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 4 + src/qemu/qemu_validate.c | 4 + src/security/security_dac.c | 2 + .../qemu_9.1.0-virt.aarch64.xml | 244 + tests/domaincapsdata/qemu_9.1.0.aarch64.xml | 244 + .../caps_9.1.0_aarch64.replies | 36222 ++++++++++++++++ .../caps_9.1.0_aarch64.xml | 530 + .../launch-security-cca.aarch64-latest.args | 30 + .../launch-security-cca.aarch64-latest.xml | 24 + tests/qemuxmlconfdata/launch-security-cca.xml | 16 + tests/qemuxmlconftest.c | 2 + 33 files changed, 37851 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_9.1.0-virt.aarch64.xml create mode 100644 tests/domaincapsdata/qemu_9.1.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml -- 2.43.5

4 14

[libvirt PATCHv2 0/7] qemu: introduce amd-iommu support
by Ján Tomko 28 May '25

28 May '25

Ján Tomko (7): qemu: introduce QEMU_CAPS_AMD_IOMMU qemu: introduce QEMU_CAPS_PCI_ID qemu: add IOMMU model amd docs: formatdomain: document intel-only IOMMU attributes conf: add passthrough and xtsup attributes for IOMMU conf: reject some attributes not applicable to intel IOMMU qemu: format pt and xstup on the command line docs/formatdomain.rst | 22 +++- src/conf/domain_conf.c | 31 +++++ src/conf/domain_conf.h | 3 + src/conf/domain_validate.c | 22 ++++ src/conf/schemas/domaincommon.rng | 11 ++ src/qemu/qemu_capabilities.c | 10 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 30 +++++ src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_validate.c | 22 ++++ .../caps_10.0.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.replies | 106 ++++++++++++------ .../caps_10.0.0_x86_64.xml | 2 + .../caps_6.2.0_x86_64.replies | 102 +++++++++++------ .../caps_6.2.0_x86_64.xml | 1 + .../caps_7.0.0_x86_64.replies | 80 +++++++------ .../caps_7.0.0_x86_64.xml | 1 + .../caps_7.1.0_x86_64.replies | 102 +++++++++++------ .../caps_7.1.0_x86_64.xml | 1 + .../caps_7.2.0_x86_64+hvf.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.replies | 102 +++++++++++------ .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.replies | 80 +++++++------ .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.replies | 102 +++++++++++------ .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.replies | 102 +++++++++++------ .../caps_8.2.0_x86_64.xml | 1 + .../caps_9.0.0_x86_64.replies | 80 +++++++------ .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.replies | 102 +++++++++++------ .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.replies | 102 +++++++++++------ .../caps_9.2.0_x86_64.xml | 1 + .../amd-iommu.x86_64-latest.args | 35 ++++++ .../amd-iommu.x86_64-latest.xml | 1 + tests/qemuxmlconfdata/amd-iommu.xml | 39 +++++++ tests/qemuxmlconftest.c | 2 + 42 files changed, 1161 insertions(+), 454 deletions(-) create mode 100644 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.args create mode 120000 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/amd-iommu.xml -- 2.49.0

1 7

[PATCH] qemu: Fix error when migration with shared TPM storage is unsupported
by Jiri Denemark 28 May '25

28 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> The VIR_ERR_NO_SUPPORT error is supposed to be used for unsupported driver APIs. It is incorrectly used when swtpm does not support migration with shared storage resulting in a rather strange error message: this function is not supported by the connection driver: the running swtpm does not support migration with shared storage The correct VIR_ERR_OPERATION_UNSUPPORTED error code provides a much better message: Operation not supported: the running swtpm does not support migration with shared storage Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_migration.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 1f91ad1117..2400750ee4 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1723,7 +1723,7 @@ qemuMigrationSrcIsAllowed(virDomainObj *vm, if (qemuTPMHasSharedStorage(driver, vm->def) && !qemuTPMCanMigrateSharedStorage(vm->def)) { - virReportError(VIR_ERR_NO_SUPPORT, "%s", + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", _("the running swtpm does not support migration with shared storage")); return false; } -- 2.49.0

2 1

[PATCH 1/1] NEWS : update NEWS for POWER11 support
by Narayana Murty N 28 May '25

28 May '25

Update NEWS.rst with the now added POWER11 processor support Signed-off-by: Narayana Murty N <nnmlinux(a)linux.ibm.com> --- NEWS.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index 0ba2d20191..fd577021b3 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -17,6 +17,10 @@ v11.4.0 (unreleased) * **New features** + * qemu: ppc64 POWER11 processor support + + Support for the recently released IBM POWER11 processor was added. + * **Improvements** * virsh: Add option ``--no-pkttyagent`` -- 2.48.1

2 1

[PATCH 0/4] An overdue deprecation, a doc fix, a bit of cleanup
by Markus Armbruster 28 May '25

28 May '25

Markus Armbruster (4): docs/about: Belatedly document tightening of QMP device_add checking qapi/migration: Deprecate migrate argument @detach docs/about/deprecated: Move deprecation notes to tidy up order docs/about/removed-features: Move removal notes to tidy up order docs/about/deprecated.rst | 47 +++++++++------------- docs/about/removed-features.rst | 69 +++++++++++++++++++-------------- qapi/migration.json | 18 ++++----- 3 files changed, 67 insertions(+), 67 deletions(-) -- 2.48.1

6 17

[PATCH] passt: Define backend hostname and fqdn
by Enrique Llorente 27 May '25

27 May '25

This commit introduces a feature enhancement for configuring hostnames in virtual machines (VMs) using DHCP. It adds new options to the "passt" tool to set the hostname and fully qualified domain name (FQDN) for VMs. These map to DHCP option 12 for the hostname and options 81 (IPv4) and 39 (IPv6) for the FQDN. The update enables passt to dynamically assign hostnames to DHCP-aware VMs. To achieve this, the commit adds two fields to the passt domain XML backend. These fields allow passt to configure the hostname and FQDN for the virtual machine, ensuring smooth integration with the DHCP protocol. This improvement is particularly valuable in environments where VMs need dynamic hostname configuration, enhancing flexibility and automation in virtualized network setups. libvirt: Integrate passt --hostname --fqdn options Resolves: https://issues.redhat.com/browse/RHEL-79806 Signed-off-by: Enrique Llorente <ellorent(a)redhat.com> --- docs/formatdomain.rst | 8 +++++--- src/conf/domain_conf.c | 10 +++++++++- src/conf/domain_conf.h | 2 ++ src/conf/schemas/domaincommon.rng | 6 ++++++ src/qemu/qemu_passt.c | 6 ++++++ tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml | 2 +- tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml | 2 +- tests/qemuxmlconfdata/net-user-passt.xml | 2 +- .../net-vhostuser-passt.x86_64-latest.xml | 2 +- tests/qemuxmlconfdata/net-vhostuser-passt.xml | 2 +- 10 files changed, 33 insertions(+), 9 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 8753ee9c23..9c80aa9270 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -5372,10 +5372,12 @@ came from the host's IP. There are a few other options that are configurable only for the passt backend. For example, the ``<backend>`` attribute ``logFile`` can be used to tell the passt process for this interface where to write its -message log, and the ``<source>`` attribute ``dev`` can tell it a +message log, the ``<source>`` attribute ``dev`` can tell it a particular host interface to use when deriving the routes given to the -guest for forwarding traffic upstream. Due to the design decisions of -passt, when using SELinux on the host, it is recommended that the log +guest for forwarding traffic upstream and the ``hostname`` and ``fqdn`` +will conigure the DHCP option 12 hostname and DHCP option 81 and DHCPv6 +option 39 fqdn attribute. Due to the design decisions of passt, when using +SELinux on the host, it is recommended that the log file reside in the runtime directory of the user under which the passt process will run, most probably ``/run/user/$UID`` (where ``$UID`` is the UID of that user), e.g. ``/run/user/1000``. Be aware that libvirt diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b3b0bd7329..15143f8fa2 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -2909,6 +2909,8 @@ virDomainNetDefFree(virDomainNetDef *def) g_free(def->backend.tap); g_free(def->backend.vhost); g_free(def->backend.logFile); + g_free(def->backend.hostname); + g_free(def->backend.fqdn); virDomainNetTeamingInfoFree(def->teaming); g_free(def->virtPortProfile); g_free(def->script); @@ -9757,6 +9759,8 @@ virDomainNetBackendParseXML(xmlNodePtr node, } def->backend.logFile = virXMLPropString(node, "logFile"); + def->backend.hostname = virXMLPropString(node, "hostname"); + def->backend.fqdn = virXMLPropString(node, "fqdn"); if (tap) def->backend.tap = virFileSanitizePath(tap); @@ -20757,7 +20761,9 @@ virDomainNetBackendIsEqual(virDomainNetBackend *src, if (src->type != dst->type || STRNEQ_NULLABLE(src->tap, dst->tap) || STRNEQ_NULLABLE(src->vhost, dst->vhost) || - STRNEQ_NULLABLE(src->logFile, dst->logFile)) { + STRNEQ_NULLABLE(src->logFile, dst->logFile) || + STRNEQ_NULLABLE(src->hostname, dst->hostname) || + STRNEQ_NULLABLE(src->fqdn, dst->fqdn)) { return false; } return true; @@ -24838,6 +24844,8 @@ virDomainNetBackendFormat(virBuffer *buf, virBufferEscapeString(&attrBuf, " tap='%s'", backend->tap); virBufferEscapeString(&attrBuf, " vhost='%s'", backend->vhost); virBufferEscapeString(&attrBuf, " logFile='%s'", backend->logFile); + virBufferEscapeString(&attrBuf, " hostname='%s'", backend->hostname); + virBufferEscapeString(&attrBuf, " fqdn='%s'", backend->fqdn); virXMLFormatElement(buf, "backend", &attrBuf, NULL); } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 58b97a2b54..79fd2f1f63 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1067,6 +1067,8 @@ struct _virDomainNetBackend { char *vhost; /* The following are currently only valid/used when backend type='passt' */ char *logFile; /* path to logfile used by passt process */ + char *hostname; /* hostname of the passt process */ + char *fqdn; /* fully qualified domain name of the passt process */ }; struct _virDomainNetPortForwardRange { diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng index 5597d5a66b..f64199ca18 100644 --- a/src/conf/schemas/domaincommon.rng +++ b/src/conf/schemas/domaincommon.rng @@ -3913,6 +3913,12 @@ <ref name="absFilePath"/> </attribute> </optional> + <optional> + <attribute name="hostname"/> + </optional> + <optional> + <attribute name="fqdn"/> + </optional> </element> </optional> <optional> diff --git a/src/qemu/qemu_passt.c b/src/qemu/qemu_passt.c index fcc34de384..9ebb766433 100644 --- a/src/qemu/qemu_passt.c +++ b/src/qemu/qemu_passt.c @@ -229,6 +229,12 @@ qemuPasstStart(virDomainObj *vm, if (net->backend.logFile) virCommandAddArgList(cmd, "--log-file", net->backend.logFile, NULL); + if (net->backend.hostname) + virCommandAddArgList(cmd, "--hostname", net->backend.hostname, NULL); + + if (net->backend.fqdn) + virCommandAddArgList(cmd, "--fqdn", net->backend.hostname, NULL); + /* Add IP address info */ for (i = 0; i < net->guestIP.nips; i++) { const virNetDevIPAddr *ip = net->guestIP.ips[i]; diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml index cfe07cc627..77da297936 100644 --- a/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml +++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-7.2.0.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml index d7e0ef5f90..917a9edaa0 100644 --- a/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/net-user-passt.x86_64-latest.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-user-passt.xml b/tests/qemuxmlconfdata/net-user-passt.xml index 20c9f50542..80d15de2ed 100644 --- a/tests/qemuxmlconfdata/net-user-passt.xml +++ b/tests/qemuxmlconfdata/net-user-passt.xml @@ -47,7 +47,7 @@ <range start='443' to='344'/> </portForward> <model type='rtl8139'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <input type='mouse' bus='ps2'/> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml index 529aff11f8..5802754c4b 100644 --- a/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml +++ b/tests/qemuxmlconfdata/net-vhostuser-passt.x86_64-latest.xml @@ -53,7 +53,7 @@ <range start='443' to='344'/> </portForward> <model type='virtio'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <interface type='vhostuser'> diff --git a/tests/qemuxmlconfdata/net-vhostuser-passt.xml b/tests/qemuxmlconfdata/net-vhostuser-passt.xml index 71b845329b..0a37511a0f 100644 --- a/tests/qemuxmlconfdata/net-vhostuser-passt.xml +++ b/tests/qemuxmlconfdata/net-vhostuser-passt.xml @@ -50,7 +50,7 @@ <range start='443' to='344'/> </portForward> <model type='virtio'/> - <backend type='passt' logFile='/var/log/loglaw.blog'/> + <backend type='passt' logFile='/var/log/loglaw.blog' hostname='hostname1' fqdn='hostname1.test.local'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <interface type='vhostuser'> -- 2.49.0

1 0

[PATCH] NEWS: Make sure releases are separated by two blank lines
by Jiri Denemark 27 May '25

27 May '25

From: Jiri Denemark <jdenemar(a)redhat.com> Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- NEWS.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index a880524ca2..0ba2d20191 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -533,6 +533,7 @@ v10.9.0 (2024-11-01) ``<blockers model='...'>`` element is added for that CPU model listing features required by the CPU model, but not supported on the host. + v10.8.0 (2024-10-01) ==================== @@ -668,6 +669,7 @@ v10.7.0 (2024-09-02) Cloud-Hypervisor driver now supports Ethernet, Network (NAT) and Bridge networking modes. + v10.6.0 (2024-08-05) ==================== -- 2.49.0

2 1

[PATCH 0/2] qemu: Fix crash when resuming failed post-copy migration
by Jiri Denemark 27 May '25

27 May '25

Jiri Denemark (2): qemu: Fix crash when resuming failed post-copy migration NEWS: Fix virtqemud crash when resuming failed post-copy migration NEWS.rst | 7 +++++++ src/qemu/qemu_migration.c | 3 ++- 2 files changed, 9 insertions(+), 1 deletion(-) -- 2.49.0

2 4

Entering freeze for libvirt-11.4.0
by Jiri Denemark 27 May '25

27 May '25

I have just tagged v11.4.0-rc1 in the repository and pushed signed tarballs to https://download.libvirt.org/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make sure the issue is more visible. If you have not done so yet, please update NEWS.rst to document any significant change you made since the last release. Jirka

1 0

[PATCH 0/9] qemu: Move config validation out of qemu_process.c
by Peter Krempa 27 May '25

27 May '25

Some more cleanups for misplaced validation of config that I've noticed when I was looking for the code validating floppies in my previous series. Peter Krempa (9): qemuDomainValidateStorageSource: Rework protocol validation into a switch statement qemu: Move disk backend validation checks from qemuProcessStartValidateDisks to qemuDomainValidateStorageSource qemu: block: Drop code for 'vxhs' storage protocol qemu.conf: Document options for VxHS block network protocol TLS config as ignored qemu: conf: Drop handling of 'vxhs' config options qemu: Move logic from qemuProcessStartValidateShmem to qemuValidateDomainDeviceDefShmem qemu: Move checks for number of listening sockets of graphics to validation code qemuProcessStartValidateGraphics: Remove redundant checks for RDP protocol features qemuProcessStartValidateGraphics: Move RDP validation logic to qemu_validate.c src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf.in | 42 +----------- src/qemu/qemu_block.c | 41 +----------- src/qemu/qemu_conf.c | 17 ----- src/qemu/qemu_conf.h | 4 -- src/qemu/qemu_domain.c | 112 +++++++++++++++---------------- src/qemu/qemu_process.c | 132 ------------------------------------- src/qemu/qemu_validate.c | 45 ++++++++++++- tests/qemuxmlconftest.c | 4 -- tests/testutilsqemu.c | 2 - 10 files changed, 101 insertions(+), 300 deletions(-) -- 2.49.0

2 10

[PATCH v2 0/3] CH: Add support for a configuration file and log level configuration
by Stefan Kober 27 May '25

27 May '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (3): ch: Add config file support ch: add log level configuration option NEWS: ch: announce log_level config option NEWS.rst | 5 +++++ src/ch/ch.conf | 11 ++++++++++ src/ch/ch_conf.c | 31 ++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 +++++++++++++++ src/ch/ch_driver.c | 6 +++++ src/ch/ch_monitor.c | 6 +++++ src/ch/libvirtd_ch.aug | 40 ++++++++++++++++++++++++++++++++++ src/ch/meson.build | 12 ++++++++++ src/ch/test_libvirtd_ch.aug.in | 5 +++++ 9 files changed, 134 insertions(+) create mode 100644 src/ch/ch.conf create mode 100644 src/ch/libvirtd_ch.aug create mode 100644 src/ch/test_libvirtd_ch.aug.in -- 2.49.0

1 3

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

26 May '25

Changelog v3 - added qemu caps check to avoid breaking s390 guests trying to default deprecated_features='off' on QEMU versions that do not support reporting these features 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 | 32 ++++++++++++++----- ...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, 110 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

3 9

[PATCH 0/4] qemu: Reflect support of floppy devices in capabilities XML
by Peter Krempa 26 May '25

26 May '25

Probe if qemu actually supports floppy controllers which can be compiled out with custom configs and reflect that in the capability XML. Peter Krempa (4): qemu: domain: Introduce qemuDomainMachineSupportsFloppy qemu: Move floppy device support validation to validation code qemu: capabilities: Introduce QEMU_CAPS_BUS_FLOPPY qemuDomainMachineSupportsFloppy: Check for QEMU_CAPS_BUS_FLOPPY src/qemu/qemu_capabilities.c | 6 ++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 15 +++++++ src/qemu/qemu_domain.h | 4 ++ src/qemu/qemu_process.c | 8 ---- src/qemu/qemu_validate.c | 7 +++ .../qemu_10.0.0-virt.aarch64.xml | 2 - tests/domaincapsdata/qemu_10.0.0.aarch64.xml | 2 - tests/domaincapsdata/qemu_10.0.0.s390x.xml | 2 - tests/domaincapsdata/qemu_8.1.0.s390x.xml | 2 - .../qemu_8.2.0-tcg-virt.loongarch64.xml | 2 - .../qemu_8.2.0-virt.aarch64.xml | 2 - .../qemu_8.2.0-virt.loongarch64.xml | 2 - tests/domaincapsdata/qemu_8.2.0.aarch64.xml | 2 - tests/domaincapsdata/qemu_8.2.0.armv7l.xml | 2 - tests/domaincapsdata/qemu_8.2.0.s390x.xml | 2 - .../qemu_9.1.0-tcg-virt.riscv64.xml | 2 - .../qemu_9.1.0-virt.riscv64.xml | 2 - tests/domaincapsdata/qemu_9.1.0.s390x.xml | 2 - .../qemu_9.2.0-hvf.aarch64+hvf.xml | 2 - tests/domaincapsdata/qemu_9.2.0.s390x.xml | 2 - .../caps_10.0.0_ppc64.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + .../caps_10.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_6.2.0_ppc64.xml | 1 + .../caps_6.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.0.0_ppc64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_7.1.0_ppc64.xml | 1 + .../caps_7.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_7.2.0_ppc.xml | 1 + .../caps_7.2.0_x86_64+hvf.xml | 1 + .../caps_7.2.0_x86_64.xml | 1 + .../caps_8.0.0_x86_64.xml | 1 + .../caps_8.1.0_x86_64.xml | 1 + .../caps_8.2.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_9.0.0_sparc.xml | 1 + .../caps_9.0.0_x86_64.xml | 1 + .../caps_9.1.0_x86_64.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + .../caps_9.2.0_x86_64.xml | 1 + .../disk-floppy-pseries.ppc64-latest.err | 2 +- .../disk-floppy-pseries.ppc64-latest.xml | 44 ------------------- tests/qemuxmlconftest.c | 2 +- 44 files changed, 53 insertions(+), 86 deletions(-) delete mode 100644 tests/qemuxmlconfdata/disk-floppy-pseries.ppc64-latest.xml -- 2.49.0

2 8

[RFC PATCH 0/2] schemas: path types refactor
by Kirill Shchetiniuk 26 May '25

26 May '25

This series of patches aims to introduce unification for path attributes in schema definitions. Previously defined types used for schema definitions are now unified into two main types: absolutePath and relativePath. This change addresses previous inconsistencies where types were sometimes used incorrectly (e.g., filePath for directory attributes). Due to prior inconsistencies, some locations now accept relative paths even if they were not explicitly intended to. To avoid such inconsistencies in the future, better names for the path types have been selected. Moreover, I suggest deprecating (with future patches) the use of relative paths in places where they are not explicitly meant to be used. This will make the schemas more consistent and, as a result, encourage users to write more deterministic XML definitions. For now the relativePath is used in such places to remain backward compatibility. Kirill Shchetiniuk (2): schemas: path types unification / refactor schemas: path attributes type refactor src/conf/schemas/basictypes.rng | 18 +--- src/conf/schemas/capability.rng | 4 +- src/conf/schemas/domainbackup.rng | 10 +- src/conf/schemas/domaincaps.rng | 2 +- src/conf/schemas/domaincheckpoint.rng | 2 +- src/conf/schemas/domaincommon.rng | 132 +++++++++++++------------- src/conf/schemas/domainsnapshot.rng | 8 +- src/conf/schemas/network.rng | 4 +- src/conf/schemas/nodedev.rng | 4 +- src/conf/schemas/secret.rng | 2 +- src/conf/schemas/storagecommon.rng | 2 +- src/conf/schemas/storagepool.rng | 10 +- src/conf/schemas/storagevol.rng | 6 +- 13 files changed, 96 insertions(+), 108 deletions(-) -- 2.49.0

1 2

[PATCH 0/2] CH: Add support for a configuration file and log level configuration
by Stefan Kober 26 May '25

26 May '25

Similar to the qemu.conf file that allows QEMU specific configurations we add the possibility to specify a ch.conf file for Cloud Hypervisor configuration. The initial single config option is the log level, which sets the verbosity of the Cloud Hypervisor process. This allows for simpler debugging when using Cloud Hypervisor via libvirt. Stefan Kober (2): ch: Add config file support ch: add log level configuration option src/ch/ch_conf.c | 32 ++++++++++++++++++++++++++++++++ src/ch/ch_conf.h | 18 ++++++++++++++++++ src/ch/ch_driver.c | 6 ++++++ src/ch/ch_monitor.c | 6 ++++++ 4 files changed, 62 insertions(+) -- 2.49.0

2 5

[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