January 2026 - Devel - libvirt List Archives

[RFC PATCH v5 0/5] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe 27 Oct '26

27 Oct '26

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 v5: - Changed the target QEMU binary (Linaro's CCA/v10 version with added QMP functionality) - Changed the following changes to the CCA QMP command definitions: - QMP command name: query-rme-guest-capabilities - CCA capabilities info - Add ARM CCA support to firmware feature. [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, (See "[software version]"below). The JSON file for the CCA firmware feature has not yet been provided by the distributor. For CCA support, the equivalent of the following JSON file must be placed in /usr/share/qemu: tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json 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://gitlab.com/Linaro/dcap/qemu/-/commits/cca/latest 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… RFC v4 https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3WAW… 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 (2): src: Add ARM CCA support in firmware feature tests: Adds Arm CCA support docs/formatdomain.rst | 46 + 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 | 146 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_cgroup.c | 2 + src/qemu/qemu_command.c | 30 + src/qemu/qemu_driver.c | 2 + src/qemu/qemu_firmware.c | 18 + src/qemu/qemu_monitor.c | 10 + src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 111 + 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_10.1.0-virt.aarch64+armrme.xml | 250 + .../qemu_10.1.0.aarch64+armrme.xml | 250 + tests/qemucapabilitiesdata/README.rst | 5 + .../caps_10.1.0_aarch64+armrme.replies | 37727 ++++++++++++++++ .../caps_10.1.0_aarch64+armrme.xml | 518 + .../qemu/firmware/50-edk2-aarch64-armcca.json | 24 + tests/qemufirmwaretest.c | 3 + ...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 + 36 files changed, 39423 insertions(+), 1 deletion(-) create mode 100644 tests/domaincapsdata/qemu_10.1.0-virt.aarch64+armrme.xml create mode 100644 tests/domaincapsdata/qemu_10.1.0.aarch64+armrme.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.1.0_aarch64+armrme.xml create mode 100644 tests/qemufirmwaredata/usr/share/qemu/firmware/50-edk2-aarch64-armcca.json 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.0

2 6

[libvirt] [PATCH 00/23] Fix host-model if the chosen CPU model has more features in QEMU compared to our cpu_map.xml
by Jiri Denemark 15 Oct '26

15 Oct '26

When decoding CPUID data to virCPUDef we need to be careful about using a CPU model which cannot be directly used on the current host. Normally, libvirt would notice the features which prevent the model from being usable and it would disable them in the computed virCPUDef, but this won't work in case the definition of the CPU model in QEMU contains more features than what we have in cpu_map.xml. We need to count with the usability blockers we got from QEMU and explicitly disable all of them to make the computed virCPUDef usable. https://bugzilla.redhat.com/show_bug.cgi?id=1464832 Jiri Denemark (23): util: Introduce virStringListCopy conf: Add usability blockers to virDomainCapsCPUModel qemu: Store CPU usability blockers in caps cache qemu: Parse unavailable features for CPU models cpu: Use virDomainCapsCPUModelsPtr in cpu driver APIs cpu: Drop unused parameter from cpuDecode cpu: Return model from virCPUModelIsAllowed cpu_x86: Move x86FeatureFind* to avoid forward prototypes cpu_x86: Disable blockers from unusable CPU models cputest: Replace json bool with enum cputest: Avoid calling json_reformat in cpu-parse.sh cputest: Print correct feature in virCPUUpdateLive test cputest: Test CPU usability blockers cputest: Separate QEMUCaps creation from cpuTestCPUIDJson build: Export virCPUModelIsAllowed private API cputest: Use CPU models from QEMU when available cputest: Add query-cpu-definitions reply for Core-i5-2540M cputest: Add CPUID data for Intel(R) Xeon(R) CPU E7-4830 cputest: Add query-cpu-definitions reply for Xeon-E7-4830 cputest: Update Xeon-E3-1245 data cputest: Add query-cpu-definitions reply for Xeon-E3-1245 cputest: Update Core-i7-2600 data cputest: Make a crippled version of Core-i7-2600 src/conf/domain_capabilities.c | 30 +- src/conf/domain_capabilities.h | 7 +- src/cpu/cpu.c | 95 +- src/cpu/cpu.h | 31 +- src/cpu/cpu_arm.c | 3 +- src/cpu/cpu_ppc64.c | 14 +- src/cpu/cpu_x86.c | 108 +- src/libvirt_private.syms | 1 + src/libxl/libxl_capabilities.c | 2 +- src/libxl/libxl_driver.c | 2 +- src/qemu/qemu_capabilities.c | 123 +-- src/qemu/qemu_capabilities.h | 6 +- src/qemu/qemu_capspriv.h | 5 + src/qemu/qemu_driver.c | 2 +- src/qemu/qemu_monitor.c | 2 + src/qemu/qemu_monitor.h | 1 + src/qemu/qemu_monitor_json.c | 26 +- src/qemu/qemu_process.c | 9 +- src/test/test_driver.c | 2 +- src/util/virstring.c | 37 + src/util/virstring.h | 3 + tests/cputest.c | 324 ++++-- tests/cputestdata/cpu-cpuid.py | 26 +- tests/cputestdata/cpu-gather.sh | 1 + tests/cputestdata/cpu-parse.sh | 2 +- tests/cputestdata/cpu-reformat.py | 9 + tests/cputestdata/x86_64-cpuid-Core-i5-2540M.json | 362 +++++++ .../x86_64-cpuid-Core-i7-2600-disabled.xml | 1 - .../x86_64-cpuid-Core-i7-2600-enabled.xml | 1 + .../cputestdata/x86_64-cpuid-Core-i7-2600-json.xml | 1 + ...x86_64-cpuid-Core-i7-2600-xsaveopt-disabled.xml | 6 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-enabled.xml | 8 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-guest.xml | 25 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-host.xml | 25 + .../x86_64-cpuid-Core-i7-2600-xsaveopt-json.xml | 11 + .../x86_64-cpuid-Core-i7-2600-xsaveopt.json | 615 +++++++++++ .../x86_64-cpuid-Core-i7-2600-xsaveopt.xml | 33 + tests/cputestdata/x86_64-cpuid-Core-i7-2600.json | 496 ++++++++- tests/cputestdata/x86_64-cpuid-Core-i7-2600.xml | 6 +- .../x86_64-cpuid-Xeon-E3-1245-disabled.xml | 1 - .../x86_64-cpuid-Xeon-E3-1245-enabled.xml | 2 +- .../cputestdata/x86_64-cpuid-Xeon-E3-1245-json.xml | 1 + tests/cputestdata/x86_64-cpuid-Xeon-E3-1245.json | 712 +++++++++---- tests/cputestdata/x86_64-cpuid-Xeon-E3-1245.xml | 7 +- .../x86_64-cpuid-Xeon-E7-4830-disabled.xml | 5 + .../x86_64-cpuid-Xeon-E7-4830-enabled.xml | 8 + .../x86_64-cpuid-Xeon-E7-4830-guest.xml | 28 + .../cputestdata/x86_64-cpuid-Xeon-E7-4830-host.xml | 29 + .../cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml | 14 + tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json | 657 ++++++++++++ tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.xml | 30 + tests/domaincapstest.c | 6 +- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1102 ++++++++++++++++++-- tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 236 ++++- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 154 ++- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 154 ++- 56 files changed, 4927 insertions(+), 680 deletions(-) create mode 100755 tests/cputestdata/cpu-reformat.py create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.json create mode 100644 tests/cputestdata/x86_64-cpuid-Core-i7-2600-xsaveopt.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-disabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-enabled.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-guest.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-host.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json create mode 100644 tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.xml -- 2.14.2

3 66

[PULL 00/32] Next pr patches
by Daniel P. Berrangé 23 Apr '26

23 Apr '26

The following changes since commit 53b41bb78950912ba2d9809eef6b45e4df30c647: Merge tag 'pull-target-arm-20251031' of https://gitlab.com/pm215/qemu into staging (2025-11-01 10:52:48 +0100) are available in the Git repository at: https://gitlab.com/berrange/qemu tags/next-pr-pull-request for you to fetch changes up to 2aaca8c6d22b18786ceff51189704113d0639590: docs: creation of x509 certs compliant with post-quantum crypto (2025-11-03 10:45:55 +0000) ---------------------------------------------------------------- Merge crypto and other misc fixes / features * Increase minimum gnutls to 3.7.5 * Increase minimum libgcrypt to 1.9.4 * Increase minimum nettle to 3.7.3 * Drop obsolete in-tree XTS impl * Fix memory leak when loading certificates * Remove/reduce duplication when loading certifcates * Fix possible crash when certificates are unloaded while an active TLS connection is using when in a TLS handshake operation * Deprecate use of dh-params.pem file * Document how to create certificates with Post-Quantum Cryptography compliant algorithms. * Support loading multiple certificate identities to allow support for Post-Quantum crypto in parallel with traditional RSA/ECC * Add "-run-with exit-with-parent=on" parameter * Flush pending errors when seeing ENOBUFS with a zero-copy send attempt * Fix data buffer parameters in hash & IO channel APIs to use 'void *' ---------------------------------------------------------------- Daniel P. Berrangé (26): crypto: bump min gnutls to 3.7.5 crypto: unconditionally enable gnutls XTS support crypto: bump min libgcrypt to 1.9.4 crypto: bump min nettle to 3.7.3 crypto: drop in-tree XTS cipher mode impl crypto: remove redundant parameter checking CA certs crypto: add missing free of certs array crypto: replace stat() with access() for credential checks crypto: remove redundant access() checks before loading certs crypto: move check for TLS creds 'dir' property crypto: use g_autofree when loading x509 credentials crypto: remove needless indirection via parent_obj field crypto: move release of DH parameters into TLS creds parent crypto: shorten the endpoint == server check in TLS creds crypto: remove duplication loading x509 CA cert crypto: reduce duplication in handling TLS priority strings crypto: introduce method for reloading TLS creds crypto: introduce a wrapper around gnutls credentials crypto: fix lifecycle handling of gnutls credentials objects crypto: make TLS credentials structs private crypto: deprecate use of external dh-params.pem file crypto: avoid loading the CA certs twice crypto: avoid loading the identity certs twice crypto: expand logic to cope with multiple certificate identities crypto: support upto 5 parallel certificate identities docs: creation of x509 certs compliant with post-quantum crypto Manish Mishra (1): io: flush zerocopy socket error queue on sendmsg failure due to ENOBUF Philippe Mathieu-Daudé (2): crypto/hash: Have hashing functions take void * buffer argument io/channel: Have read/write functions take void * buffer argument Richard W.M. Jones (2): Implement -run-with exit-with-parent=on tests/qtest: Use exit-with-parent=on in qtest invocations Tejus GK (1): io: add a "blocking" field to QIOChannelSocket crypto/cipher-gnutls.c.inc | 8 - crypto/cipher-nettle.c.inc | 44 -- crypto/cipher.c | 2 +- crypto/hash.c | 16 +- crypto/hmac.c | 8 +- crypto/meson.build | 10 +- crypto/tlscreds.c | 79 ++-- crypto/tlscredsanon.c | 64 +-- crypto/tlscredsbox.c | 101 +++++ crypto/tlscredsbox.h | 50 +++ crypto/tlscredspriv.h | 36 +- crypto/tlscredspsk.c | 64 ++- crypto/tlscredsx509.c | 593 +++++++++++++++++--------- crypto/tlssession.c | 139 ++---- crypto/trace-events | 1 + crypto/xts.c | 250 ----------- docs/about/deprecated.rst | 9 + docs/system/tls.rst | 134 +++++- include/crypto/hash.h | 8 +- include/crypto/hmac.h | 4 +- include/crypto/tlscreds.h | 26 ++ include/crypto/tlscredsx509.h | 6 + include/crypto/tlssession.h | 4 +- include/crypto/xts.h | 82 ---- include/io/channel-socket.h | 6 + include/io/channel.h | 14 +- include/qemu/exit-with-parent.h | 57 +++ io/channel-socket.c | 86 +++- io/channel-tls.c | 4 +- io/channel.c | 14 +- meson.build | 69 +-- qemu-options.hx | 13 +- system/exit-with-parent.c | 140 ++++++ system/meson.build | 1 + system/vl.c | 13 + tests/qtest/libqtest.c | 22 +- tests/unit/meson.build | 3 - tests/unit/test-crypto-block.c | 3 +- tests/unit/test-crypto-tlscredsx509.c | 8 +- tests/unit/test-crypto-tlssession.c | 4 +- tests/unit/test-crypto-xts.c | 529 ----------------------- ui/vnc.c | 9 +- 42 files changed, 1208 insertions(+), 1525 deletions(-) create mode 100644 crypto/tlscredsbox.c create mode 100644 crypto/tlscredsbox.h delete mode 100644 crypto/xts.c delete mode 100644 include/crypto/xts.h create mode 100644 include/qemu/exit-with-parent.h create mode 100644 system/exit-with-parent.c delete mode 100644 tests/unit/test-crypto-xts.c -- 2.51.1

3 36

Re: Clarification Needed: virsh snapshot-delete Behavior with External Snapshots (--disk-only)
by Peter Krempa 10 Apr '26

10 Apr '26

On Wed, Jul 23, 2025 at 04:57:57 +0000, P, Rajasekar via Users wrote: > Hello libvirt community, > > I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option). > > **Environment:** > - libvirt version: 10.5.0 Note that this was released almost a year ago. > - Kernel version: 5.14.0-503.22.1.el9_5.x86_64 > - Disk image format: qcow2 > - Host OS: RHEL 9.5 > > **Steps to reproduce:** > 1. Create an external snapshot: > virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic > 2. Delete the snapshot: > virsh snapshot-delete <vm> --snapshotname snap1 > > **Observed behavior:** > - Changes from the overlay (snapshot) file are merged into the base image. > - The snapshot metadata is removed from libvirt. > - The snapshot file remains on disk (appears orphaned). You mean that the original overlay images remained on disk? e.g. /path/to/originalimage.snap1 ? > **Questions:** > - Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step. Yes it is intended, because deleting a snapshot is effectively meaning "I don't want to return to this point any more" so the extra overlay makes no sense. > - Should the snapshot file be deleted automatically, or is manual cleanup required? If you mean the overlay, then yes it should have been deleted. > - Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots? The semantics of external and internal snapshots are supposed to be indentical. I don't think we document to a deep extent the actual behaviour WRT to the disk files.

2 1

[PATCH] qemu: migration: Call hook script on source host at migration start
by Guy Godfroy 07 Apr '26

07 Apr '26

Currently, the qemu hook script with the "migrate" operation is only called on the destination host at the beginning of incoming migration. This makes it impossible for the source host to prepare for migration, for example to change storage locks from exclusive to shared mode when using shared LVM storage with lvmlockd. Add a hook call on the source host at the beginning of outgoing migration. The hook is called with "source" as the extra argument to distinguish it from the destination hook which uses "-". The same change is also applied to the libxl driver for consistency. Resolves: https://gitlab.com/libvirt/libvirt/-/issues/37 Signed-off-by: Guy Godfroy <guy.godfroy(a)gugod.fr> --- docs/hooks.rst | 36 ++++++++++++++++++++++++++++++++---- src/libxl/libxl_migration.c | 17 +++++++++++++++++ src/qemu/qemu_migration.c | 17 +++++++++++++++++ 3 files changed, 66 insertions(+), 4 deletions(-) diff --git a/docs/hooks.rst b/docs/hooks.rst index e1745b8cc7..4c7cac56ba 100644 --- a/docs/hooks.rst +++ b/docs/hooks.rst @@ -244,7 +244,7 @@ operation. There is no specific operation to indicate a "restart" is occurring. - :since:`Since 0.9.11`, the qemu hook script is also called at the beginning - of incoming migration. It is called as: + of incoming migration on the **destination** host. It is called as: :: @@ -257,6 +257,18 @@ operation. There is no specific operation to indicate a "restart" is occurring. is not valid, incoming migration will be canceled. This hook may be used, e.g., to change location of disk images for incoming domains. +- :since:`Since 12.1.0`, the qemu hook script is also called at the beginning + of outgoing migration on the **source** host. It is called as: + + :: + + /etc/libvirt/hooks/qemu guest_name migrate begin source + + with domain XML sent to standard input of the script. Unlike the destination + hook, this script does not act as a filter and any output is ignored. If the + script returns failure, the migration will be canceled. This hook may be used, + e.g., to change storage lock mode from exclusive to shared before migration. + - :since:`Since 1.2.9`, the qemu hook script is also called when restoring a saved image either via the API or automatically when restoring a managed save machine. It is called as: @@ -417,7 +429,7 @@ operation. There is no specific operation to indicate a "restart" is occurring. /etc/libvirt/hooks/libxl guest_name release end - - :since:`Since 2.1.0`, the libxl hook script is also called at the beginning - of incoming migration. It is called as: + of incoming migration on the **destination** host. It is called as: :: @@ -430,6 +442,18 @@ operation. There is no specific operation to indicate a "restart" is occurring. is not valid, incoming migration will be canceled. This hook may be used, e.g., to change location of disk images for incoming domains. +- :since:`Since 12.1.0`, the libxl hook script is also called at the beginning + of outgoing migration on the **source** host. It is called as: + + :: + + /etc/libvirt/hooks/libxl guest_name migrate begin source + + with domain XML sent to standard input of the script. Unlike the destination + hook, this script does not act as a filter and any output is ignored. If the + script returns failure, the migration will be canceled. This hook may be used, + e.g., to change storage lock mode from exclusive to shared before migration. + - :since:`Since 6.5.0`, you can also place several hook scripts in the directory ``/etc/libvirt/hooks/libxl.d/``. They are executed in alphabetical order after main script. In this case each script also acts as filter and can @@ -566,10 +590,14 @@ Migration of a QEMU guest involves running hook scripts on both the source and destination hosts: #. At the beginning of the migration, the *qemu* hook script on the - **destination** host is executed with the "migrate" operation. + **source** host is executed with the "migrate" operation and "source" + as the extra argument (:since:`since 12.1.0`). This allows the source + host to prepare for migration, e.g., changing storage locks. +#. Then, the *qemu* hook script on the **destination** host is executed + with the "migrate" operation. #. Before QEMU process is spawned, the two operations ("prepare" and "start") called for domain start are executed on **destination** host. -#. If both of these hook script executions exit successfully (exit status 0), +#. If all of these hook script executions exit successfully (exit status 0), the migration continues. Any other exit code indicates failure, and the migration is aborted. #. The QEMU guest is then migrated to the destination host. diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c index f5dee7627b..76f3c7ceb7 100644 --- a/src/libxl/libxl_migration.c +++ b/src/libxl/libxl_migration.c @@ -411,6 +411,23 @@ libxlDomainMigrationSrcBegin(virConnectPtr conn, if (!libxlDomainMigrationIsAllowed(def)) goto endjob; + /* Call hook to allow source host to prepare for migration */ + if (virHookPresent(VIR_HOOK_DRIVER_LIBXL)) { + g_autofree char *hookxml = NULL; + int hookret; + + if (!(hookxml = virDomainDefFormat(def, driver->xmlopt, + VIR_DOMAIN_DEF_FORMAT_SECURE))) + goto endjob; + + hookret = virHookCall(VIR_HOOK_DRIVER_LIBXL, def->name, + VIR_HOOK_LIBXL_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN, + "source", hookxml, NULL); + + if (hookret < 0) + goto endjob; + } + xml = virDomainDefFormat(def, driver->xmlopt, VIR_DOMAIN_DEF_FORMAT_SECURE); /* Valid xml means success! EndJob in the confirm phase */ if (xml) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 6dd022163b..60e370319c 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2791,6 +2791,23 @@ qemuMigrationSrcBeginPhase(virQEMUDriver *driver, if (!qemuMigrationSrcIsAllowed(vm, true, vm->job->asyncJob, flags)) return NULL; + /* Call hook to allow source host to prepare for migration */ + if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { + g_autofree char *xml = NULL; + int hookret; + + if (!(xml = qemuDomainDefFormatLive(driver, priv->qemuCaps, vm->def, + priv->origCPU, false, true))) + return NULL; + + hookret = virHookCall(VIR_HOOK_DRIVER_QEMU, vm->def->name, + VIR_HOOK_QEMU_OP_MIGRATE, VIR_HOOK_SUBOP_BEGIN, + "source", xml, NULL); + + if (hookret < 0) + return NULL; + } + if (!(flags & (VIR_MIGRATE_UNSAFE | VIR_MIGRATE_OFFLINE)) && !qemuMigrationSrcIsSafe(vm, migrate_disks, flags)) return NULL; -- 2.34.1

4 18

[RFC] Reintroducing customisable hotplug timeouts
by Akash Kulhalli 30 Mar '26

30 Mar '26

I'd like to resurface an earlier proposal [1] to make the unplug timeout user-configurable. With production guests running sustained, non-trivial workloads, we find that hot(un)plug operations regularly takes longer than the current default of 5s. However, the inability to easily configure this timeout means that in the worst case a recompilation with appropriate values set is required for each deployment, which is cumbersome to maintain and patch. The previous proposal [1] also initially made the timeout configurable, however that was specifically for the ppc64 architecture. Therefore, imposing this change for an entire architecture made sense, since it was a universal requirement for that platform. With deployment environments as diverse and varied as x86, having a single, inconfigurable value does not make as much sense now. For x86, such a change is not ideal since the desired timeout value depends very heavily on the deployment environment in use - if it is being performed by a human anything more than 10s is an undesirable user experience [2], as pointed out in the original discussion. However, more relaxed timeout values (e.g. 15-20s) can be more acceptable if the operations are background/ not directly user-facing. It is in these cases where the ability to change the timeout more easily becomes more desirable. To prevent misconfiguration, while maintaining the same out-of-box experience for existing users, I'd also like to propose the following- 1. As mentioned in the original proposal [1], the timeout cannot be set to a value lower than the default timeout of 5s; in these cases a warning will be emitted and the timeout will be reset to the default value. 2. Including an upper cap would also be desirable, in my opinion - any API consumer should not wait endlessly for an async operation to finish. 3. This configuration option will only be described in qemu.conf, not imposed - the out-of-box experience will remain unchanged at the current default (5s) for everyone who does not wish to tweak/is unaware of this value. An administrator who knowingly changes these values is therefore not blindsided by any perceived "hangs" resulting from the use of an increased timeout window. Since this would be a clearly documented and explicitly opt-in behaviour, the benefits in the form of easy modification based on evolving operational needs would be quite significant. Given the varying nature of production environments and specific operational needs at scale, it would therefore be beneficial to reconsider the merits of the original proposal. [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/TXYV… [2] https://www.nngroup.com/articles/response-times-3-important-limits/

4 12

[PATCH v2] virhostcpu: Fix potential use of unallocated memory
by Felix Huettner 26 Mar '26

26 Mar '26

In case of a host that has a large number of cpus offline the count of host cpus and the last bit set in the virHostCPUGetOnlineBitmap might diverge significantly. This can e.g. be the case when disabling smt via /sys/devices/system/cpu/smt/control. On the host this looks like: ``` $ cat /sys/devices/system/cpu/present 0-255 $ cat /sys/devices/system/cpu/online 0-127 ``` However in this case virBitmapToData previously only allocated 16 bytes for the output bitmap. This is becase the last set bit is on the 15th byte. Users of virHostCPUGetMap however rely on the "cpumap" containing enough space for all existing cpus (so they would expect 32 bytes in this case). E.g. cmdNodeCpuMap relies on this for its output. It will then actually read 32 bytes from the start of the "cpumap" address where in this case the last 16 of these bytes are uninitialized. This manifests itself in flapping outputs of "virsh nodecpumap --pretty" like: ``` $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,202 $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,197 $ virsh nodecpumap --pretty CPUs present: 256 CPUs online: 128 CPU map: 0-127,192,194,196-197 ``` This in turn potentially causes users of this data to report wrong cpu counts. Note that this only seems to happen with at least 256 physical cpus where at least 128 are offline. We fix this by preallocating the expected bitmap size. Signed-off-by: Felix Huettner <felix.huettner(a)stackit.cloud> --- src/util/virhostcpu.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 5dbcc8987c..4805484b1d 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -1090,28 +1090,26 @@ virHostCPUGetMap(unsigned char **cpumap, unsigned int flags) { g_autoptr(virBitmap) cpus = NULL; - int ret = -1; - int dummy; + int ncpus = virHostCPUGetCount(); virCheckFlags(0, -1); if (!cpumap && !online) - return virHostCPUGetCount(); + return ncpus; if (!(cpus = virHostCPUGetOnlineBitmap())) - goto cleanup; + return -1; + + if (cpumap) { + int len = (ncpus + CHAR_BIT) / CHAR_BIT; + *cpumap = g_new0(unsigned char, len); + virBitmapToDataBuf(cpus, *cpumap, len); + } - if (cpumap) - virBitmapToData(cpus, cpumap, &dummy); if (online) *online = virBitmapCountBits(cpus); - ret = virHostCPUGetCount(); - - cleanup: - if (ret < 0 && cpumap) - VIR_FREE(*cpumap); - return ret; + return ncpus; } base-commit: c5a73f75bc6cae4f466d0a6344d5b3277ac9c2f4 -- 2.43.0

2 1

[PATCH v7 0/2] qemu: Support accelerated vSMMUs
by Nathan Chen 11 Mar '26

11 Mar '26

Hi, This is a follow up to the sixth RFC patchset [0] for supporting multiple accelerated vSMMU instances. Support for user-creatable accelerated SMMUv3 in QEMU has been applied to target-arm.next [1]. For instance, specifying hostdevs associated with multiple accelerated SMMUs, configured to be routed to pcie-expander-bus controllers in a way where VFIO device to SMMUv3 associations are matched with the host: <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> <vpasidCapOffset>0xff8</vpasidCapOffset> <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> <vpasidCapOffset>0xff8</vpasidCapOffset> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> <iommu model='smmuv3'> <driver parentIdx='1' accel='on' ats='on' ril='off' ssidSize='20' oas='44'/> </iommu> <iommu model='smmuv3'> <driver parentIdx='2' accel='on' ats='on' ril='off' ssidSize='20' oas='44'/> </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"}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.1","id":"iommu0","accel":true,"ats":true,"ril":false,"ssidsize":20,"oas":44}' \ -device '{"driver":"arm-smmuv3","primary-bus":"pci.2","id":"iommu1","accel":true,"ats":true,"ril":false,"ssidsize":20,"oas":44}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","x-vpasid-cap-offset":4088,"bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","x-vpasid-cap-offset":4088,"bus":"pci.22","addr":"0x0"}' \ This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/smmuv3-accel-01-26-v7/ Thanks, Nathan Changes from v6: - Remove smmuv3 'pasid' attribute - Add smmuv3 'ssidsize' attribute - Add support for 'vpasidCapOffset' element - Modify logic for building accel smmuv3 qemu command line to omit ATS, RIL, accel flags when not needed (enabled/disabled by default in QEMU SMMUv3) [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VRSS… [1] https://lore.kernel.org/qemu-devel/20260126104342.253965-1-skolothumtho@nvi… Nathan Chen (2): qemu: Add support for HW-accelerated nested SMMUv3 tests: qemuxmlconfdata: provide HW-accel smmuv3 sample XML and CLI args docs/formatdomain.rst | 36 +++++++ src/conf/domain_conf.c | 101 +++++++++++++++++- src/conf/domain_conf.h | 6 ++ src/conf/domain_validate.c | 36 ++++++- src/conf/schemas/domaincommon.rng | 32 ++++++ src/qemu/qemu_command.c | 23 ++++ src/util/virpci.h | 4 + ...u-smmuv3-pci-bus-accel.aarch64-latest.args | 38 +++++++ ...mu-smmuv3-pci-bus-accel.aarch64-latest.xml | 64 +++++++++++ .../iommu-smmuv3-pci-bus-accel.xml | 54 ++++++++++ tests/qemuxmlconftest.c | 1 + 11 files changed, 390 insertions(+), 5 deletions(-) create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommu-smmuv3-pci-bus-accel.xml -- 2.43.0

2 9

[PATCH 0/3] Add 'scalable_mode' and 'first_stage' attributes to intel IOMMU
by Zhenzhong Duan 06 Mar '26

06 Mar '26

Hi, This adds 'scalable_mode' and 'first_stage' attributes to intel IOMMU so that emulated device can run with first stage translation. This is based on Nathan Chen's iommufd series v2[1], so for passthrough device, nested tranlation is enabled automatically with below config: <iommu model='intel'> <driver caching_mode='on' iotlb='on' scalable_mode='on' first_stage='on'/> </iommu> Tests: Basic net card passthrough libvirt selftest Thanks Zhenzhong [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KFYU… Zhenzhong Duan (3): qemu: Introduce scalable_mode and first_stage capabilities conf: add support for 'scalable_mode' and 'first_stage' attributes to intel IOMMU qemu: Add command line support for scalable mode and first stage of virtual vtd docs/formatdomain.rst | 8 +++++ src/conf/domain_conf.c | 35 ++++++++++++++++++- src/conf/domain_conf.h | 2 ++ src/conf/domain_validate.c | 6 ++++ src/conf/schemas/domaincommon.rng | 10 ++++++ src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 2 ++ src/qemu/qemu_command.c | 2 ++ src/qemu/qemu_validate.c | 12 +++++++ .../caps_10.0.0_x86_64+amdsev.xml | 2 ++ .../caps_10.0.0_x86_64.xml | 2 ++ .../caps_10.1.0_x86_64+inteltdx.xml | 2 ++ .../caps_10.1.0_x86_64.xml | 2 ++ .../caps_10.2.0_x86_64.xml | 2 ++ .../caps_6.2.0_x86_64.xml | 1 + .../caps_7.0.0_x86_64.xml | 1 + .../caps_7.1.0_x86_64.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 + .../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 + 26 files changed, 102 insertions(+), 1 deletion(-) -- 2.47.3

3 7

[PULL 02/18] deprecation: don't enable TCG plugins by default with TCI
by Alex Bennée 27 Feb '26

27 Feb '26

The softmmu memory instrumentation test sees so many more accesses than a normal translated host and its really not worth fixing up. Lets deprecate this odd configuration and save on the CI cycles. Reviewed-by: Pierrick Bouvier <pierrick.bouvier(a)linaro.org> Signed-off-by: Alex Bennée <alex.bennee(a)linaro.org> Message-Id: <20240916085400.1046925-3-alex.bennee(a)linaro.org> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 809b2b9b81..c0aa52def5 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -196,6 +196,14 @@ benefits from having plenty of host memory it seems reasonable to encourage users to use 64 bit builds of QEMU for analysis work whatever targets they are instrumenting. +TCG Plugin support not enabled by default with TCI (since 9.2) +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +While the TCG interpreter can interpret the TCG ops used by plugins it +is going to be so much slower it wouldn't make sense for any serious +instrumentation. Due to implementation differences there will also be +anomalies in things like memory instrumentation. + System emulator CPUs -------------------- diff --git a/configure b/configure index cc8e1ed5b8..aa7aae70fa 100755 --- a/configure +++ b/configure @@ -629,6 +629,9 @@ meson_option_parse() { exit 1 fi } +has_meson_option() { + test "${meson_options#*"$1"}" != "$meson_options" +} meson_add_machine_file() { if test "$cross_compile" = "yes"; then @@ -1048,8 +1051,12 @@ if test "$static" = "yes" ; then plugins="no" fi if test "$plugins" != "no" && test $host_bits -eq 64; then - plugins=yes - subdirs="$subdirs contrib/plugins" + if has_meson_option "-Dtcg_interpreter=true"; then + plugins="no" + else + plugins=yes + subdirs="$subdirs contrib/plugins" + fi fi cat > $TMPC << EOF -- 2.39.5

2 1