- Devel - libvirt List Archives

[PATCH 0/2] qemu: capabilities: Update '10.2' capabilities on x86_64 after release
by Peter Krempa 07 Jan '26

07 Jan '26

Peter Krempa (2): qemucapabilitiesdata: Re-generate 'caps_10.2.0_x86_64' qemu: capabilities: Update '10.2' capabilities on x86_64 after release .../domaincapsdata/qemu_10.2.0-q35.x86_64.xml | 170 +++++++++++-- tests/domaincapsdata/qemu_10.2.0.x86_64.xml | 170 +++++++++++-- .../caps_10.2.0_x86_64.replies | 230 +++++++++++++----- .../caps_10.2.0_x86_64.xml | 157 ++++++++++-- ...host-model-fallback-kvm.x86_64-latest.args | 2 +- ...cpu-host-model-features.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-latest.args | 2 +- ...st-model-nofallback-kvm.x86_64-latest.args | 2 +- 8 files changed, 618 insertions(+), 117 deletions(-) -- 2.52.0

2 3

[PATCH v4 0/9] Enable mshv support for Qemu domains
by Praveen K Paladugu 07 Jan '26

07 Jan '26

This patch set introduces changes within libvirt to lauch Qemu guests with Microsoft Hypervisor(mshv). Qemu exposes this capability as 'mshv' accelerator type. Below is an excerpt of domain XML with mshv accelerator.: ``` <domain type='hyperv'> <name>qemu_mshv_test</name> <os> <type machine='q35'>hvm</type> </os> ... ``` 'mshv' accelerator within Qemu translates to 'hyperv' domains in Libvirt. Changs in v4: - Adopted `query-accelerators` API to get mshv capabilities. - Fixed virtytpe parsing in schemas. Chages in v3: - Addressed review comments on v2. - fixed qemucapabilitiestest case - Added a case to qemuxmlconftest Changes in v2: - Addressed review comments on v1. - Added a test to verify mshv capabilities. Eugene Fedorenko (1): qemu: Append mshv to hwaccel list. Praveen K Paladugu (8): qemu: Introduce mshv capabilities qemu: Query and use mshv capabilities qemu: use mshv accel for hyperv domains qemu: conditionally add /dev/mshv to acl conf: Fix virttype handling in schemas tests: Add domaincaps case for mshv tests: qemucapabilities: Introduce MSHV capability tests:qemuxmlconftest: Add case for hyperv domains src/conf/schemas/basictypes.rng | 22 + src/conf/schemas/capability.rng | 14 +- src/conf/schemas/domaincommon.rng | 23 +- src/qemu/qemu_capabilities.c | 39 +- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 6 + src/qemu/qemu_command.c | 4 +- src/qemu/qemu_namespace.c | 2 + src/qemu/qemu_process.c | 2 +- .../qemu_10.2.0-q35.x86_64+mshv.xml | 222 + .../qemu_10.2.0-tcg.x86_64+mshv.xml | 2334 + .../qemu_10.2.0.x86_64+mshv.xml | 222 + .../caps_10.2.0_x86_64+mshv.replies | 45176 ++++++++++++++++ .../caps_10.2.0_x86_64+mshv.xml | 3212 ++ .../qemucaps2xmloutdata/caps.x86_64+mshv.xml | 29 + ...86_64-q35-headless.x86_64-latest+mshv.args | 48 + ...x86_64-q35-headless.x86_64-latest+mshv.xml | 87 + ...mshv-x86_64-q35-headless.x86_64-latest.err | 1 + .../mshv-x86_64-q35-headless.xml | 35 + tests/qemuxmlconftest.c | 5 + 20 files changed, 51446 insertions(+), 38 deletions(-) create mode 100644 tests/domaincapsdata/qemu_10.2.0-q35.x86_64+mshv.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0-tcg.x86_64+mshv.xml create mode 100644 tests/domaincapsdata/qemu_10.2.0.x86_64+mshv.xml create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_x86_64+mshv.replies create mode 100644 tests/qemucapabilitiesdata/caps_10.2.0_x86_64+mshv.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+mshv.xml create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.x86_64-latest+mshv.args create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.x86_64-latest+mshv.xml create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/mshv-x86_64-q35-headless.xml -- 2.51.0

4 24

[PATCH] libvirt-guests.service: use Type=exec
by Antonio Terceiro 07 Jan '26

07 Jan '26

Type=oneshot means that the service is only considered started after the main process exits. In setups where libvirt-guests is configured to be used and imposes a delay on the startup of guests, this will cause systemd to report a quite high boot time as it will wait until all guests have booted, plus all the delay between them. High boot times are often reported as issues in monitoring systems, and require operator attention, while in this case there is not really an issue with the system, it's just doing what it was configured to do. With Type=exec, the service is considered started right after the main process is *started*, but the boot process will not wait for it. Having other units depend on libvirt-guests.service finishing was already not reliable because one cannot know how long the OS inside each guest takes to boot, and libvirt-guests already does not wait for them to be in any particular state. Signed-off-by: Antonio Terceiro <terceiro(a)debian.org> --- tools/libvirt-guests.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libvirt-guests.service.in b/tools/libvirt-guests.service.in index b044444298..c8e4d3d749 100644 --- a/tools/libvirt-guests.service.in +++ b/tools/libvirt-guests.service.in @@ -19,7 +19,7 @@ EnvironmentFile=-@initconfdir@/libvirt-guests # out the code ExecStart=@libexecdir@/libvirt-guests.sh start ExecStop=@libexecdir@/libvirt-guests.sh stop -Type=oneshot +Type=exec RemainAfterExit=yes StandardOutput=journal+console TimeoutStopSec=0 -- 2.51.0

3 4

[PATCH] docs: fix broken UUID example
by Daniel P. Berrangé 06 Jan '26

06 Jan '26

From: Daniel P. Berrangé <berrange(a)redhat.com> The UUID had only 11 characters in the last component, instead of the required 12. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/formatsecret.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/formatsecret.rst b/docs/formatsecret.rst index d4e0cb9ddb..bbf2fc22ea 100644 --- a/docs/formatsecret.rst +++ b/docs/formatsecret.rst @@ -73,7 +73,7 @@ passphrase to decrypt the volume, :since:`since 2.1.0`. An example follows: # cat luks-secret.xml <secret ephemeral='no' private='yes'> <description>LUKS Sample Secret</description> - <uuid>f52a81b2-424e-490c-823d-6bd4235bc57</uuid> + <uuid>f52a81b2-424e-490c-823d-6bd4235bc507</uuid> <usage type='volume'> <volume>/var/lib/libvirt/images/luks-sample.img</volume> </usage> @@ -91,7 +91,7 @@ The volume type secret can be supplied in domain XML for a luks storage volume :: <encryption format='luks'> - <secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc57'/> + <secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc507'/> </encryption> Usage type "ceph" -- 2.52.0

2 2

[PATCH 00/36] qemu: Improvements and fixes to firmware selection
by Andrea Bolognani 06 Jan '26

06 Jan '26

This series improves validation so that more nonsensical configurations are rejected, fixes a number of scenarios in which user-provided attributes were getting overwritten by the firmware selection process, and overall makes things more predictable and reliable. Notably, it addresses the inability of starting confidential VMs on aarch64, which was reported[1] some time ago. It is also a prerequisite of another series that I will post shortly, which introduces support for the uefi-vars QEMU device and thus makes it possible to use Secure Boot for aarch64 VMs. Since all these fixes and improvements make sense on their own, and there is a little bit of work still needed on the QEMU/edk2 side before the other series can be merged, I decided to post this one separately instead of lumping them together. It's not like it's not meaty enough on its own anyway :) [1] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/D5UD… Andrea Bolognani (36): qemu_firmware: Drop support for kernel descriptors qemu_firmware: Drop 'nvram' local variable qemu_firmware: Move format=raw compat exception qemu_firmware: Move copying of nvram.format to loader.format tests: Add firmware-manual-efi-rw-nvram domain_validate: Reject NVRAM with read/write firmware tests: Add firmware-auto-bios-rw tests: Add firmware-manual-bios-rw domain_validate: Reject read/write ROMs tests: Add firmware-auto-efi-format-loader-qcow2-rom domain_validate: Reject ROMs with format other than raw qemu_firmware: Ignore stateless/combined when NVRAM is configured qemu_firmware: Drop fallback for absent nvramTemplateFormat schemas: Allow templateFormat without template path tests: Add firmware-manual-efi-nvram-template-nonstandard-format tests: Add firmware-manual-efi-nvram-template-nonstandard-legacy-paths tests: Add firmware-auto-efi-format-nvram-raw tests: Add firmware-auto-efi-format-nvram-raw-loader-path tests: Add firmware-auto-efi-format-nvram-raw-nvramtemplate-path tests: Add firmware-auto-efi-format-nvramtemplate-qcow2 tests: Add firmware-auto-efi-format-mismatch-nvramtemplate qemu_firmware: Introduce qemuFirmwareFillDomainCustom() qemu_firmware: Set templateFormat for custom paths qemu_firmware: Simplify handling of legacy paths qemu_firmware: Refactor setting NVRAM format qemu_firmware: Prefer template format to loader format qemu_firmware: Retain user-specified NVRAM format qemu_firmware: Take templateFormat into account when matching qemu_firmware: Take NVRAM format into account when matching qemu_firmware: Remove NVRAM to loader format copy hack tests: Add firmware-manual-efi-sev-snp tests: Add firmware-manual-efi-tdx qemu_firmware: ROM firmware is always in raw format qemu_firmware: Don't skip autoselection for ROM qemu_firmware: Allow matching both UEFI and BIOS for ROM loader news: Mention improvements and fixes to firmware selection NEWS.rst | 8 + src/conf/domain_conf.c | 18 +- src/conf/domain_validate.c | 30 ++ src/conf/schemas/domaincommon.rng | 10 +- src/qemu/qemu_firmware.c | 367 ++++++++++-------- src/qemu/qemu_postparse.c | 17 - .../firmware-auto-bios-rw.x86_64-latest.err | 1 + ...> firmware-auto-bios-rw.x86_64-latest.xml} | 5 +- .../qemuxmlconfdata/firmware-auto-bios-rw.xml | 18 + ...-format-loader-qcow2-rom.x86_64-latest.err | 1 + ...mware-auto-efi-format-loader-qcow2-rom.xml | 18 + ...t-mismatch-nvramtemplate.x86_64-latest.err | 1 + ...-mismatch-nvramtemplate.x86_64-latest.xml} | 6 +- ...auto-efi-format-mismatch-nvramtemplate.xml | 19 + ...uto-efi-format-mismatch.x86_64-latest.args | 5 +- ...auto-efi-format-mismatch.x86_64-latest.xml | 2 +- ...-nvram-raw-loader-path.x86_64-latest.args} | 4 +- ...t-nvram-raw-loader-path.x86_64-latest.xml} | 4 +- ...-auto-efi-format-nvram-raw-loader-path.xml | 19 + ...raw-nvramtemplate-path.x86_64-latest.args} | 4 +- ...-raw-nvramtemplate-path.x86_64-latest.xml} | 4 +- ...fi-format-nvram-raw-nvramtemplate-path.xml | 18 + ...t-nvram-raw.x86_64-latest.abi-update.args} | 0 ...at-nvram-raw.x86_64-latest.abi-update.xml} | 0 ...o-efi-format-nvram-raw.x86_64-latest.args} | 0 ...to-efi-format-nvram-raw.x86_64-latest.xml} | 0 .../firmware-auto-efi-format-nvram-raw.xml | 18 + ...at-nvramtemplate-qcow2.x86_64-latest.args} | 9 +- ...mat-nvramtemplate-qcow2.x86_64-latest.xml} | 4 +- ...re-auto-efi-format-nvramtemplate-qcow2.xml | 18 + .../firmware-manual-bios-rw.x86_64-latest.err | 1 + .../firmware-manual-bios-rw.xml | 15 + ...-loader-path-nonstandard.x86_64-latest.xml | 2 +- ...ate-nonstandard-format.x86_64-latest.args} | 10 +- ...late-nonstandard-format.x86_64-latest.xml} | 4 +- ...-efi-nvram-template-nonstandard-format.xml | 19 + ...nstandard-legacy-paths.x86_64-latest.args} | 4 +- ...onstandard-legacy-paths.x86_64-latest.xml} | 5 +- ...vram-template-nonstandard-legacy-paths.xml | 20 + ...ram-template-nonstandard.x86_64-latest.xml | 2 +- ...ware-manual-efi-rw-nvram.x86_64-latest.err | 1 + .../firmware-manual-efi-rw-nvram.xml | 19 + ...ual-efi-sev-snp.x86_64-latest+amdsev.args} | 7 +- ...nual-efi-sev-snp.x86_64-latest+amdsev.xml} | 12 +- .../firmware-manual-efi-sev-snp.xml | 21 + ...anual-efi-tdx.x86_64-latest+inteltdx.args} | 9 +- ...manual-efi-tdx.x86_64-latest+inteltdx.xml} | 11 +- .../firmware-manual-efi-tdx.xml | 25 ++ tests/qemuxmlconftest.c | 19 + 49 files changed, 571 insertions(+), 263 deletions(-) create mode 100644 tests/qemuxmlconfdata/firmware-auto-bios-rw.x86_64-latest.err copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-auto-bios-rw.x86_64-latest.xml} (83%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-bios-rw.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-loader-qcow2-rom.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-loader-qcow2-rom.xml create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch-nvramtemplate.x86_64-latest.err copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-auto-efi-format-mismatch-nvramtemplate.x86_64-latest.xml} (83%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-mismatch-nvramtemplate.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw-loader-path.x86_64-latest.args} (90%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw-loader-path.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-raw-loader-path.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw-nvramtemplate-path.x86_64-latest.args} (90%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw-nvramtemplate-path.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-raw-nvramtemplate-path.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw.x86_64-latest.abi-update.args} (100%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw.x86_64-latest.abi-update.xml} (100%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvram-raw.x86_64-latest.args} (100%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvram-raw.x86_64-latest.xml} (100%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvram-raw.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-auto-efi-format-nvramtemplate-qcow2.x86_64-latest.args} (77%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-auto-efi-format-nvramtemplate-qcow2.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-auto-efi-format-nvramtemplate-qcow2.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-bios-rw.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-manual-bios-rw.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-nvram-template-nonstandard-format.x86_64-latest.args} (70%) copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-manual-efi-nvram-template-nonstandard-format.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-nvram-template-nonstandard-format.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-nvram-template-nonstandard-legacy-paths.x86_64-latest.args} (89%) copy tests/qemuxmlconfdata/{firmware-manual-efi-loader-path-nonstandard.x86_64-latest.xml => firmware-manual-efi-nvram-template-nonstandard-legacy-paths.x86_64-latest.xml} (81%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-nvram-template-nonstandard-legacy-paths.xml create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-rw-nvram.x86_64-latest.err create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-rw-nvram.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-sev-snp.x86_64-latest+amdsev.args} (74%) copy tests/qemuxmlconfdata/{firmware-manual-efi-nvram-template-nonstandard.x86_64-latest.xml => firmware-manual-efi-sev-snp.x86_64-latest+amdsev.xml} (75%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-sev-snp.xml copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.args => firmware-manual-efi-tdx.x86_64-latest+inteltdx.args} (59%) copy tests/qemuxmlconfdata/{firmware-auto-efi-format-mismatch.x86_64-latest.xml => firmware-manual-efi-tdx.x86_64-latest+inteltdx.xml} (69%) create mode 100644 tests/qemuxmlconfdata/firmware-manual-efi-tdx.xml -- 2.52.0

3 38

[PATCH] tools: check for failure decoding secret base64 value
by Daniel P. Berrangé 06 Jan '26

06 Jan '26

From: Daniel P. Berrangé <berrange(a)redhat.com> The g_base64_decode function will return a valid pointer, but with length of zero when it fails to decode data. Report an error in that scenario, so avoid a later more obsecure error. eg old behaviour # virsh secret-set-value f52a81b2-424e-490c-823d-6bd4235bc507 foo warning: Passing secret value as command-line argument is insecure! error: Failed to set secret value error: value in virSecretSetValue must not be NULL new behaviour # /home/berrange/virsh secret-set-value f52a81b2-424e-490c-823d-6bd4235bc507 foo warning: Passing secret value as command-line argument is insecure! error: Secret value is not valid base64 Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- tools/virsh-secret.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tools/virsh-secret.c b/tools/virsh-secret.c index 26ecb41073..215e8e1017 100644 --- a/tools/virsh-secret.c +++ b/tools/virsh-secret.c @@ -267,6 +267,11 @@ cmdSecretSetValue(vshControl *ctl, const vshCmd *cmd) secret_val = (char *) g_base64_decode(tmp, &secret_len); virSecureErase(tmp, tmp_len); + + if (!secret_len) { + vshError(ctl, "%s", _("Secret value is not valid base64")); + return false; + } } res = virSecretSetValue(secret, (unsigned char *) secret_val, secret_len, 0); -- 2.52.0

2 1

[PATCH v2 0/5] cover: RFE libvirt secret encryption on disk
by Arun Menon 06 Jan '26

06 Jan '26

Libvirt secrets are stored unencrypted on the disk. With this series we want to start encrypting the secrets. 1. Introduce the GnuTLS decryption wrapper functions that work exact opposite to the encryption wrappers. 2. Add a new service called virt-secrets-init-encryption, that is linked to the virtsecretd and libvirtd service. virtsecretd and libvirtd services only starts after the new service generates a random encryption key. 3. Add a new secret.conf configuration file that helps user to set a. secrets_encryption_key - allows the user to specify the encryption key file path, in case the default key is not to be used. b. encrypt_data - set to 0 or 1. If set to 1, then the newly added secrets will be encrypted. 4. Rename the file name attribute in virSecretObj structure to secretValueFile. 5. Once we have the encryption key, and a reliable way to tell the daemon what encryption scheme the secret object is using, we can encrypt the secrets on disk and store them in <uuid>.<encryption_scheme> format. It is important to note that if the encryption key is changed between restarts, then the respective secret will not be loaded by the driver. This is a sincere attempt to improve upon the already submitted patch https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KE6G… Resolves: https://issues.redhat.com/browse/RHEL-7125 --- Changes in v2: - Fixed a regression in the decryption logic. ciphertext length was incorrectly calculated. - Removed virSecretEncryptionScheme enum. It is no longer required. All the changes will be done at one place i.e. schemeInfo array. In future we can append to the array, when we want to add new cipher modes. - Add Requires= and After= directives in libvirtd service. Remove unnecessary configuration settings from src/secret meson.build. - Other minor refactoring and header include fix. Arun Menon (5): util: Add support for GnuTLS decryption secret: Set up default encryption secret key for the virtsecretd service secret: Add secret.conf configuration file and parse it secret: Rename virSecretObj structure attribute from base64File to secretValueFile secret: Add functionality to load and save secrets in encrypted format include/libvirt/virterror.h | 1 + libvirt.spec.in | 7 + po/POTFILES | 1 + src/conf/virsecretobj.c | 183 ++++++++++++++---- src/conf/virsecretobj.h | 18 +- src/libvirt_private.syms | 1 + src/meson.build | 1 + src/remote/libvirtd.service.in | 4 + src/secret/libvirt_secrets.aug | 40 ++++ src/secret/meson.build | 31 +++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 179 +++++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 34 +++- src/secret/test_libvirt_secrets.aug.in | 6 + .../virt-secret-init-encryption.service.in | 8 + src/secret/virtsecretd.service.extra.in | 8 + src/util/vircrypto.c | 126 +++++++++++- src/util/vircrypto.h | 8 + src/util/virerror.c | 3 + tests/vircryptotest.c | 65 +++++++ 21 files changed, 728 insertions(+), 50 deletions(-) create mode 100644 src/secret/libvirt_secrets.aug create mode 100644 src/secret/secret.conf.in create mode 100644 src/secret/secret_config.c create mode 100644 src/secret/secret_config.h create mode 100644 src/secret/test_libvirt_secrets.aug.in create mode 100644 src/secret/virt-secret-init-encryption.service.in -- 2.51.1

2 8

[RFC 00/10] qom: Support marking object properties as deprecated
by Zhao Liu 06 Jan '26

06 Jan '26

Hi, This RFC is the follow-up work of v2.6 & v2.7 machines' removal [*], and tries to introduce a general way to provide deprecation hint for external user. Its core idea is to detect external property settings (as well as specific internal property settings, such as the compat property). I think deprecated properties and internal-only properties are quite similar, as both require consideration of external property usage. But the former only triggers a warning, while the latter stops all external access attempts. For simplicity, this RFC series only considers deprecated properties. Brief Introduction ================== Now the common (but a bit fragmented) way to mark a property deprecated is to add the warning in its accssors, or just document the deprecation in docs/about/deprecated.rst without any hint when someone touches that property. Ideally, it's better to provide some hints to external user when he tries to set the property via command line or HMP. But this is pretty inconvenient (even impossible) for such qdev properties, which are defined via DEFINE_PROP_* macros in the Property array. For qdev properties, their accessors are provided by pre-defined PropertyInfo, so that it's possible to modify PropertyInfo for a single "deprecated" property. Then it's necessary to introduce property flags to mark some properties as deprecated, and to check the property flags when set the property, thereby to print a deprecation warning. This not only benefits traditional qdev properties but also helps the deprecation of generic objects. Note, internal attempt (except the compat case) should not trigger the deprecation warning but external user should see the deprecation information. I think the most complex part is identifying the paths for property settings (both external command-line options and internal specific configurations). This series currently covers the following scenarios (which I consider to be particularly important): External cases: 1) External global properties: * -global command line option. * -cpu command line features. * suger properties from object_compat_props[2] 2) External ("TYPE_USER_CREATABLE") object: * -object command line used for external ("TYPE_USER_CREATABLE") object. 3) External device: * -device command line - parsed based on keyval or json. 4) External machine options: * -machine command line - parsed based on keyval. 5) External accelerator options: * -accel command line. 6) HMP command: * "qom-set" command. Internal cases: 1) internal global properties: * compat properties from object_compat_props[0,1]. 2) Internal machine options: * Builtin default machine options string: MachineClass::default_machine_opts - parsed based on keyval, too. In fact, there are still some special device command lines that haven't been considered yet. But I believe the remaining cases can be gradually expanded? If this approach is feasible, it's possible to further introduce an "internal" flag to prevent external access to compat property. [*]: hw/i386/pc: Remove deprecated 2.6 and 2.7 PC machines https://lore.kernel.org/qemu-devel/20251202162835.3227894-1-zhao1.liu@intel… Thanks and Best Regards, Zhao --- Zhao Liu (10): qom: Rename ObjectPropertyFlags to ObjectPropertyAccessorFlags qom: Add basic object property deprecation hint support qom: Check property deprecation flag for global property qom: Check property deprecation flag for properities from qdict system/vl: Check property deprecation flag for properities of accelerator qom/qom-hmp-cmd: Check property deprecation flag for "qom-set" command hw/core/qdev-properties: Allow to mark qdev property as deprecated target/i386: Deprecate fill-mtrr-mask property target/i386: Deprecate cpuid-0xb property hw/intc/ioapic: Deprecate version property docs/about/deprecated.rst | 31 +++++++++ hw/core/qdev-properties.c | 24 +++---- hw/intc/ioapic.c | 3 +- include/hw/qdev-properties.h | 18 ++++++ include/qom/object.h | 120 +++++++++++++++++++++++++++++++---- qom/object.c | 101 ++++++++++++++++++++++------- qom/object_interfaces.c | 2 +- qom/qom-hmp-cmds.c | 2 +- system/vl.c | 2 +- target/i386/cpu.c | 4 +- 10 files changed, 253 insertions(+), 54 deletions(-) -- 2.34.1

2 18

[PATCH v3 0/7] qemu: Implement support for iommufd
by Nathan Chen 06 Jan '26

06 Jan '26

From: Nathan Chen <nathanc(a)nvidia.com> Hi, This is a follow up to the second patch series [0] for using iommufd to propagate DMA mappings to the kernel for VM-assigned host devices in a qemu VM. We add a new 'iommufd' attribute for hostdev devices to be associated with the iommufd object. For instance, specifying the iommufd object and associated hostdev in a VM definition: <devices> ... <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0009' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x15' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='no'> <driver iommufd='yes'/> <source> <address domain='0x0019' bus='0x01' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x16' slot='0x00' function='0x0'/> </hostdev> ... </devices> This would get translated to a qemu command line with the arguments below. Note that libvirt will open the /dev/iommu and VFIO cdev, passing the associated fd number to qemu: -object '{"qom-type":"iommufd","id":"iommufd0","fd":"24"}' \ -device '{"driver":"vfio-pci","host":"0009:01:00.0","id":"hostdev0","iommufd":"iommufd0","fd":"22","bus":"pci.21","addr":"0x0"}' \ -device '{"driver":"vfio-pci","host":"0019:01:00.0","id":"hostdev1","iommufd":"iommufd0","fd":"25","bus":"pci.22","addr":"0x0"}' \ Changes from v2: - Set per-process memory accounting mode for iommufd - Separated out formatting of iommufd object from qemuBuildHostdevCommandLine - Placed hostdev private data implementation in a separate commit - Allocate hostdev private data unconditionally - Compare FDs against -1 - Integrated callback function in virQEMUDriverPrivateDataCallbacks for qemuDomainHostdevPrivateNew - Dropped qemuProcessCloseVfioFds - Addressed other feedback from v2 (formatting, includes, etc.) - Revised seclabel logic to be device-specific for AppArmor and to allow paths for SELinux/DAC Thanks to Ján Tomko for sharing some of the above changes in a personal repo. I have included changes directly from that repo and added Suggested-by or Signed-off-by tags on various commits containing the changes. This series is on Github: https://github.com/NathanChenNVIDIA/libvirt/tree/iommufd-12-25 Thanks, Nathan [0] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/KFYU… Signed-off-by: Nathan Chen <nathanc(a)nvidia.com> Nathan Chen (7): qemu: Implement support for associating iommufd to hostdev qemu: Introduce privateData for hostdevs qemu: open VFIO FDs from libvirt backend qemu: open iommufd FD from libvirt backend qemu: Set per-process memory accounting for iommufd qemu: Update Cgroup, namespace, and seclabel for iommufd tests: qemuxmlconfdata: provide iommufd sample XML and CLI args cover letter: qemu: Implement support for iommufd docs/formatdomain.rst | 7 + po/POTFILES | 1 + src/bhyve/bhyve_parse_command.c | 2 +- src/conf/device_conf.c | 11 ++ src/conf/device_conf.h | 1 + src/conf/domain_conf.c | 13 +- src/conf/domain_conf.h | 5 +- src/conf/schemas/basictypes.rng | 5 + src/libvirt_private.syms | 4 + src/libxl/xen_common.c | 2 +- src/libxl/xen_xl.c | 2 +- src/lxc/lxc_native.c | 2 +- src/qemu/qemu_cgroup.c | 26 ++-- src/qemu/qemu_command.c | 74 ++++++++++ src/qemu/qemu_domain.c | 41 ++++++ src/qemu/qemu_domain.h | 20 +++ src/qemu/qemu_namespace.c | 16 ++- src/qemu/qemu_process.c | 126 ++++++++++++++++++ src/security/security_apparmor.c | 33 ++++- src/security/security_dac.c | 60 +++++++-- src/security/security_selinux.c | 58 ++++++-- src/security/virt-aa-helper.c | 32 ++++- src/util/meson.build | 1 + src/util/viriommufd.c | 89 +++++++++++++ src/util/viriommufd.h | 23 ++++ src/util/virpci.c | 69 ++++++++++ src/util/virpci.h | 2 + src/vbox/vbox_common.c | 2 +- .../iommufd-q35.x86_64-latest.args | 41 ++++++ .../iommufd-q35.x86_64-latest.xml | 60 +++++++++ tests/qemuxmlconfdata/iommufd-q35.xml | 38 ++++++ .../iommufd-virt.aarch64-latest.args | 33 +++++ .../iommufd-virt.aarch64-latest.xml | 34 +++++ tests/qemuxmlconfdata/iommufd-virt.xml | 22 +++ .../iommufd.x86_64-latest.args | 35 +++++ .../qemuxmlconfdata/iommufd.x86_64-latest.xml | 38 ++++++ tests/qemuxmlconfdata/iommufd.xml | 30 +++++ tests/qemuxmlconftest.c | 33 +++++ tests/virhostdevtest.c | 2 +- 39 files changed, 1031 insertions(+), 62 deletions(-) create mode 100644 src/util/viriommufd.c create mode 100644 src/util/viriommufd.h create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-q35.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-q35.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd-virt.aarch64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd-virt.xml create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.args create mode 100644 tests/qemuxmlconfdata/iommufd.x86_64-latest.xml create mode 100644 tests/qemuxmlconfdata/iommufd.xml -- 2.43.0

3 19

[PATCH 0/3] bhyve: add virtio-scsi support
by Roman Bogorodskiy 06 Jan '26

06 Jan '26

Roman Bogorodskiy (3): conf: introduce CTL storage type bhyve: add virtio-scsi support docs: bhyve: document virtio-scsi support docs/drvbhyve.rst | 19 +++++ docs/formatdomain.rst | 5 ++ src/bhyve/bhyve_command.c | 73 ++++++++++++++++++- src/bhyve/bhyve_device.c | 1 + src/bhyve/bhyve_process.c | 1 + src/ch/ch_monitor.c | 1 + src/conf/domain_conf.c | 7 ++ src/conf/schemas/domaincommon.rng | 13 ++++ src/conf/storage_source_conf.c | 6 +- src/conf/storage_source_conf.h | 1 + src/libxl/xen_xl.c | 1 + src/qemu/qemu_block.c | 2 + src/qemu/qemu_command.c | 1 + src/qemu/qemu_migration.c | 3 + src/qemu/qemu_process.c | 1 + src/qemu/qemu_snapshot.c | 4 + src/qemu/qemu_validate.c | 1 + src/storage_file/storage_source.c | 1 + .../bhyvexml2argv-virtio-scsi.args | 10 +++ .../bhyvexml2argv-virtio-scsi.ldargs | 4 + .../bhyvexml2argv-virtio-scsi.xml | 21 ++++++ tests/bhyvexml2argvtest.c | 1 + .../bhyvexml2xmlout-virtio-scsi.xml | 32 ++++++++ tests/bhyvexml2xmltest.c | 1 + 24 files changed, 205 insertions(+), 5 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-scsi.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-scsi.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-virtio-scsi.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-virtio-scsi.xml -- 2.52.0

2 6