- Devel - libvirt List Archives

[PATCH v2 0/4] qemu: Add support for control of persistent reservation migration
by Peter Krempa 12 Feb '26

12 Feb '26

Add support for migration of persistent reservations. The qemu support was just merged in. Patches 1 and 2 are new, patch 3 is rebased on top of new capability, patch 4 is identical to the RFC version. Peter Krempa (4): qemucapabilitiestest: Update 'caps_11.0.0_x86_64' to 'v10.2.0-1114-gb3abdfa486' qemucapabilitiestest: Update 'caps_11.0.0_aarch64' to t'v10.2.0-1114-gb3abdfa486' qemu: capabilities: Introduce QEMU_CAPS_DEVICE_SCSI_BLOCK_MIGRATE_PR qemu: Implement support for persistent reservation migration control docs/formatdomain.rst | 3 + src/conf/domain_conf.c | 21 + src/conf/schemas/storagecommon.rng | 5 + src/conf/storage_source_conf.c | 10 + src/conf/storage_source_conf.h | 2 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 4 + src/qemu/qemu_validate.c | 16 + .../caps_11.0.0_aarch64.replies | 3631 +++++++++-------- .../caps_11.0.0_aarch64.xml | 9 +- .../caps_11.0.0_x86_64.replies | 3557 ++++++++-------- .../caps_11.0.0_x86_64.xml | 11 +- ...irtio-scsi-reservations.x86_64-latest.args | 2 +- .../disk-virtio-scsi-reservations.xml | 2 +- 15 files changed, 3681 insertions(+), 3599 deletions(-) -- 2.53.0

2 5

[PATCH v3 0/4] Add multitouch input device support
by Julio Faracco 12 Feb '26

12 Feb '26

This patch series implements support for multitouch input devices in libvirt, addressing the multitouch feature request in [1]. In this third version, all the commits compile and have the test passed independently. This version includes docs updates too. They are logically separated in: 1. Domain enums, qemu, security, and capabilities updates. 2. Domain schema update. 3. Domain format doc update. 4. Test cases updates for multitouch support. [1] https://gitlab.com/libvirt/libvirt/-/issues/808 Julio Faracco (4): Add support for virtio-multitouch input devices conf: Add multitouch to domain schema docs: Add multitouch input type information tests: Add multitouch support to virtio-input tests docs/formatdomain.rst | 13 ++++++++----- src/conf/domain_audit.c | 1 + src/conf/domain_conf.c | 2 ++ src/conf/domain_conf.h | 1 + src/conf/domain_validate.c | 9 +++++++++ src/conf/schemas/domaincommon.rng | 1 + src/qemu/qemu_capabilities.c | 5 +++++ src/qemu/qemu_capabilities.h | 3 +++ src/qemu/qemu_command.c | 5 +++++ src/qemu/qemu_validate.c | 5 +++++ src/security/security_dac.c | 2 ++ src/security/security_selinux.c | 2 ++ tests/qemucapabilitiesdata/caps_10.0.0_aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_s390x.xml | 1 + .../caps_10.0.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_10.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_10.1.0_s390x.xml | 1 + .../caps_10.1.0_x86_64+inteltdx.xml | 1 + tests/qemucapabilitiesdata/caps_10.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_10.2.0_aarch64.xml | 1 + .../caps_10.2.0_x86_64+mshv.xml | 1 + tests/qemucapabilitiesdata/caps_10.2.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_11.0.0_aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_11.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_8.1.0_s390x.xml | 1 + tests/qemucapabilitiesdata/caps_8.1.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_armv7l.xml | 1 + .../qemucapabilitiesdata/caps_8.2.0_loongarch64.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_s390x.xml | 1 + tests/qemucapabilitiesdata/caps_8.2.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.0.0_x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_riscv64.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_s390x.xml | 1 + tests/qemucapabilitiesdata/caps_9.1.0_x86_64.xml | 1 + .../qemucapabilitiesdata/caps_9.2.0_aarch64+hvf.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_s390x.xml | 1 + .../caps_9.2.0_x86_64+amdsev.xml | 1 + tests/qemucapabilitiesdata/caps_9.2.0_x86_64.xml | 1 + .../qemuxmlconfdata/virtio-input.x86_64-latest.args | 1 + .../qemuxmlconfdata/virtio-input.x86_64-latest.xml | 3 +++ tests/qemuxmlconfdata/virtio-input.xml | 1 + 43 files changed, 77 insertions(+), 5 deletions(-) -- 2.52.0

1 4

[PATCH 0/4] hyperv: Implement virDomainInterfaceAddresses()
by Michal Privoznik 12 Feb '26

12 Feb '26

*** BLURB HERE *** Michal Prívozník (4): datatypes: Declare autofree func for virDomainInterface type virsocketaddr: Introduce virSocketAddrSubnetToPrefix() hyperv: Move MAC parsing into a separate function hyperv: Implement virDomainInterfaceAddresses() src/datatypes.h | 2 + src/hyperv/hyperv_driver.c | 228 +++++++++++++++++++++++--- src/hyperv/hyperv_wmi_generator.input | 12 ++ src/libvirt_private.syms | 1 + src/util/virsocketaddr.c | 51 ++++++ src/util/virsocketaddr.h | 2 + tests/sockettest.c | 29 ++++ 7 files changed, 300 insertions(+), 25 deletions(-) -- 2.52.0

4 14

[PATCH v2 0/4] hyperv: Implement virDomainInterfaceAddresses()
by Michal Privoznik 12 Feb '26

12 Feb '26

v2 of: diff to v1: - In 2/4 document corner case behavior of virSocketAddrSubnetToPrefix, - In 2/4 make the test report actual and expected values, - In 4/4 fix a possible mem leak if hypervDomainInterfaceAddressesParseOne() fails Michal Prívozník (4): datatypes: Declare autofree func for virDomainInterface type virsocketaddr: Introduce virSocketAddrSubnetToPrefix() hyperv: Move MAC parsing into a separate function hyperv: Implement virDomainInterfaceAddresses() src/datatypes.h | 2 + src/hyperv/hyperv_driver.c | 226 +++++++++++++++++++++++--- src/hyperv/hyperv_wmi_generator.input | 12 ++ src/libvirt_private.syms | 1 + src/util/virsocketaddr.c | 53 ++++++ src/util/virsocketaddr.h | 2 + tests/sockettest.c | 33 ++++ 7 files changed, 304 insertions(+), 25 deletions(-) -- 2.52.0

1 4

[PATCH v5 00/24] util: sync error_report & qemu_log output more closely
by Daniel P. Berrangé 12 Feb '26

12 Feb '26

This series is a tangent that came out of discussion in https://lists.nongnu.org/archive/html/qemu-devel/2025-08/msg00903.html In thinking about adding thread info to error_report, I came to realize we should likely make qemu_log behave consistently with error_report & friends. We already honour '-msg timestamp=on', but don't honour 'guest-name=on' and also don't include the binary name. As an example of the current state, consider mixing error and log output today: - Default context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55ac6d97f700 dir=fish qcrypto_tls_creds_get_path TLS creds path creds=0x55ac6d97f700 filename=ca-cert.pem path=<none> qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such file or directory - Full context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' \ -msg guest-name=on,timestamp=on \ -name "fish food" 2025-08-19T20:14:16.791413Z qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55e9a3458d10 dir=fish 2025-08-19T20:14:16.791429Z qcrypto_tls_creds_get_path TLS creds path creds=0x55e9a3458d10 filename=ca-cert.pem path=<none> 2025-08-19T20:14:16.791433Z fish food qemu-system-x86_64: Unable to access credentials fish/ca-cert.pem: No such file or directory And after this series is complete: - Default context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' qemu-system-x86_64(1184284:main): qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x55a24ad5cb30 dir=fish qemu-system-x86_64(1184284:main): qcrypto_tls_creds_get_path TLS creds path creds=0x55a24ad5cb30 filename=ca-cert.pem path=<none> qemu-system-x86_64(1184284:main): Unable to access credentials fish/ca-cert.pem: No such file or directory - Full context: # qemu-system-x86_64 -object tls-creds-x509,id=t0,dir=fish \ -d 'trace:qcrypto*' \ -msg guest-name=on,timestamp=on \ -name "fish food" 2025-08-19T20:12:50.211823Z [fish food] qemu-system-x86_64(1168876:main): qcrypto_tls_creds_x509_load TLS creds x509 load creds=0x5582183d8760 dir=fish 2025-08-19T20:12:50.211842Z [fish food] qemu-system-x86_64(1168876:main): qcrypto_tls_creds_get_path TLS creds path creds=0x5582183d8760 filename=ca-cert.pem +path=<none> 2025-08-19T20:12:50.211846Z [fish food] qemu-system-x86_64(1168876:main): Unable to access credentials fish/ca-cert.pem: No such file or directory The main things to note: * error_report/warn_report/qemu_log share the same output format and -msg applies to both * -msg debug-threads=on is now unconditionally enabled and thus the param is deprecated & ignored * Thread ID and name are unconditionally enabled * Guest name is surrounded in [...] brackets * The default output lines are typically 15 chars wider given that we always include the thread ID + name now * This takes the liberty of assigning the new file to the existing error-report.c maintainer (Markus) Since splitting it off into message.c instead of putting it all in error-report.c felt slightly nicer. One thing I didn't tackle is making the location info get reported for qemu_log. This is used to give context for error messages when parsing some CLI args, and could be interesting for log messages associated with those same CLI args. Changes in v5: - Remove redundant [] around values in qemu-options.hx - Use g_strlcpy instead of strlcpy - Remove redundant !! around a value that was already bool - Improve the qemu_lock_trylock() API docs to encourage use of fprintf() instead of further qemu_log() calls - Add a qemu_log_trylock_context() counterpart for qemu_log_trylock that includes the message context - Don't scan for \n to determine whether we can output a message context prefix or not. Instead track call depth on qemu_log_trylock() and only output it when the depth was initially zero. This fixes linux-user -strace output formatting which was mangled by v4 - Use fprintf(stderr) instead of error_printf_mon in cases where mon would be NULL - Use fputs/fputc in simple cases where we don't need the full power of fprintf - Use qemu_f{un}lockfile instead of f{un}lockfile - Add -msg thread-info=on|off,program-name=on|off args to allow default message prefixes to be optionally disabled Changes in v4: - Re-architected the way error_vprintf() operates to simplify monitor dependency - Fixed the move of error_vprintf from monitor.c to error-report.c so that unit tests can still get a stub to capture messages to g_test_message - Simplify changes to vreport() to avoid passing around function pointers - Add locking of stderr to vreport() to serialize incremental output - Fix thread naming logic changes on Windows - Change deprecation warning messages Changes in v3: - Stop formatting a string in qmessage_context, instead output directly to a "FILE *" stream - Fix pre-existing bug interleaving qemu_log and vreport when the trace 'log' backend has mutex probes enabled Changes in v2: - Re-use existing qemu_get_thread_id rather than re-inventing it as qemu_thread_get_id. - Expose qemu_thread_set_name and use it from all locations needing to set thread names - Fix qemu_log() to skip context prefix when emitting a log message in fragments across multiple calls - Skip allocating memory for empty context messages - Fix leak in win32 impl of qemu_thread_get_name - Use g_strlcpy where possible Daniel P. Berrangé (24): qemu-options: remove extraneous [] around arg values include: define constant for early constructor priority monitor: initialize global data from a constructor system: unconditionally enable thread naming util: expose qemu_thread_set_name audio: make jackaudio use qemu_thread_set_name util: set the name for the 'main' thread util: add API to fetch the current thread name util: introduce some API docs for logging APIs util: avoid repeated prefix on incremental qemu_log calls ui/vnc: remove use of error_printf_unless_qmp() monitor: remove redundant error_[v]printf_unless_qmp monitor: refactor error_vprintf() monitor: move error_vprintf back to error-report.c monitor: introduce monitor_cur_is_hmp() helper util: don't skip error prefixes when QMP is active util: fix interleaving of error & trace output util: fix interleaving of error prefixes util: introduce common helper for error-report & log code util: convert error-report & log to message API for timestamp util: add support for formatting a workload name in messages util: add support for formatting a program name in messages util: add support for formatting thread info in messages util: add brackets around guest name in message context MAINTAINERS | 2 + audio/jackaudio.c | 30 +++++-- docs/about/deprecated.rst | 7 ++ include/monitor/monitor.h | 4 +- include/qemu/compiler.h | 8 ++ include/qemu/error-report.h | 4 - include/qemu/log-for-trace.h | 17 +++- include/qemu/log.h | 38 +++++++++ include/qemu/message.h | 40 +++++++++ include/qemu/thread.h | 3 +- meson.build | 21 +++++ monitor/monitor.c | 61 +++++--------- qemu-options.hx | 121 ++++++++++++++------------- rust/util/src/log.rs | 6 ++ storage-daemon/qemu-storage-daemon.c | 6 ++ stubs/error-printf.c | 23 ----- stubs/meson.build | 1 - stubs/monitor-core.c | 20 ++++- system/vl.c | 49 +++++++++-- tests/qemu-iotests/041 | 2 +- tests/qemu-iotests/common.filter | 2 +- tests/unit/test-error-report.c | 6 +- tests/unit/test-util-sockets.c | 1 + ui/vnc.c | 14 ++-- util/error-report.c | 97 ++++++++++++--------- util/log.c | 47 ++++++----- util/meson.build | 1 + util/message.c | 51 +++++++++++ util/qemu-thread-posix.c | 77 +++++++++++------ util/qemu-thread-win32.c | 87 +++++++++++++------ 30 files changed, 580 insertions(+), 266 deletions(-) create mode 100644 include/qemu/message.h delete mode 100644 stubs/error-printf.c create mode 100644 util/message.c -- 2.52.0

4 71

[PATCH v6 0/6] cover: RFE libvirt secret encryption on disk
by Arun Menon 12 Feb '26

12 Feb '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 service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.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. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. 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. 6. Add documentation. 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 v6: - changes to use obj->secretValueFile as base - does local suffix lookups - refactors code so that the base64 encoding is in common code paths - moves local variable declaration inside blocks using them - refactors loader to use virFileReadAll instead of open-coding - fixes virSecretObjDeleteData to not rely on the actual filename Changes in v5: - Fix the bug of updating old secrets, prior to 12.1.0. Old secrets, when updated, now are stored with the latest encryption scheme if encryption is on. - Remove any logic in setting the secretValueFile in virSecretObjListAdd. Move it to virSecretLoadValue and virSecretObjSetValue. - Change urandom to random. Change default permission bits to 0077. - Update the documentation. Changes in v4: - Fix the regression of loading unencrypted secrets after an upgrade. Previously the .base64 unencrypted secrets were not being loaded. - Add documentation on encrypted secrets. Changes in v3: - Secrets xml configuration no longer stores the encryption scheme, therefore not allowing the user to toggle between ciphers. - Removed unnecessary socket files of the new service. It now has a general configuration with which it starts. - Addressed review comments from Peter on coding style and design. - Loading of secrets is dependent on the file extension. Most recent cipher is used while saving the secrets. Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (6): 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 docs: secret: Add documentation of secret encryption feature docs/drvsecret.rst | 4 + docs/meson.build | 1 + docs/secretencryption.rst | 105 +++++++++ include/libvirt/virterror.h | 1 + libvirt.spec.in | 8 + po/POTFILES | 1 + src/conf/virsecretobj.c | 210 +++++++++++++----- src/conf/virsecretobj.h | 14 +- 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 | 32 +++ src/secret/secret.conf.in | 14 ++ src/secret/secret_config.c | 179 +++++++++++++++ src/secret/secret_config.h | 40 ++++ src/secret/secret_driver.c | 29 ++- 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 ++++++ 24 files changed, 840 insertions(+), 68 deletions(-) create mode 100644 docs/secretencryption.rst 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

1 6

[PATCH v5 0/6] cover: RFE libvirt secret encryption on disk
by Arun Menon 12 Feb '26

12 Feb '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 service. virtsecretd service only starts after the new service generates a random encryption key. 3. Add a new secrets.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. Add encryption scheme or cipher attribute that will allow us to choose the last used cipher. 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. 6. Add documentation. 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 v5: - Fix the bug of updating old secrets, prior to 12.1.0. Old secrets, when updated, now are stored with the latest encryption scheme if encryption is on. - Remove any logic in setting the secretValueFile in virSecretObjListAdd. Move it to virSecretLoadValue and virSecretObjSetValue. - Change urandom to random. Change default permission bits to 0077. - Update the documentation. Changes in v4: - Fix the regression of loading unencrypted secrets after an upgrade. Previously the .base64 unencrypted secrets were not being loaded. - Add documentation on encrypted secrets. Changes in v3: - Secrets xml configuration no longer stores the encryption scheme, therefore not allowing the user to toggle between ciphers. - Removed unnecessary socket files of the new service. It now has a general configuration with which it starts. - Addressed review comments from Peter on coding style and design. - Loading of secrets is dependent on the file extension. Most recent cipher is used while saving the secrets. Changes in v2: - Corrected the encryption key length check. It should be 32. - Added a new patch that introduces the encryption scheme attribute. This will help us identify which secrets are encrypted. - A new systemd unit service file added that starts before virtsecretd, helping us to construct a random encryption key and pass it to the virtsecretd service. - Parsing logic of secrets.conf moved to a separate file. - Spec file changes, augeas. Arun Menon (6): 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 docs: secret: Add documentation of secret encryption feature docs/drvsecret.rst | 4 + docs/meson.build | 1 + docs/secretencryption.rst | 105 +++++++ include/libvirt/virterror.h | 1 + libvirt.spec.in | 8 + po/POTFILES | 1 + src/conf/virsecretobj.c | 259 +++++++++++++----- src/conf/virsecretobj.h | 16 +- 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 | 32 +++ src/secret/secret.conf.in | 14 + src/secret/secret_config.c | 179 ++++++++++++ src/secret/secret_config.h | 40 +++ src/secret/secret_driver.c | 31 ++- 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 +++++ 24 files changed, 892 insertions(+), 69 deletions(-) create mode 100644 docs/secretencryption.rst 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 11

Re: [PATCH v2 00/21] qom: introduce property flags to track external user input
by Daniel P. Berrangé 12 Feb '26

12 Feb '26

On Wed, Feb 11, 2026 at 03:06:23PM +0800, Zhao Liu wrote: > > So the main thing that pushes us into using QOM for internal properties > > is the machine type compatibility code. eg where we bulk set stuff using > > > > compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len); > > compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len); > > > > That logic is all QOM based. Using QOM isn't our exclusive approach, as > > we have machine types sometimes setting object fields directly. eg > > > > static void pc_i440fx_machine_7_0_options(MachineClass *m) > > { > > PCMachineClass *pcmc = PC_MACHINE_CLASS(m); > > pc_i440fx_machine_7_1_options(m); > > pcmc->enforce_amd_1tb_hole = false; > > compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len); > > compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len); > > } > > > > but that only works for properties against the machine type, not compat > > properties against devices, since we have no direct access to the other > > classes/instances. > > Right, and setting fields directly is only possible for machine-level > state, not for device properties created dynamically during > realize/init. So QOM-based compat properties are indeed inescapable > for devices. > > > If we want to be able to control hardware compat, without exposing > > something as a user facing tunable, then internal-only QOM props seems > > inescapable. > > Agreed. > > > I do still wonder if we genuinely need internal-only QOM props for > > machine type compat ? > > > > Whether using a public 'x-' prefixed property or an internal only > > property, we're constrained by the need to retain the behaviour > > semantics for as long as the machine type exists. I don't see an > > internal only property giving us significantly more freedom here. > > We can already rename a 'x-' property however we want with no > > notice, as long as the machine type doesn't change behaviour. > > Hmm, I think x- prefix is already semantically overloaded. Looking at > the current codebase, x- carries two very different meanings: > > - "unstable but user-facing feature" - e.g. x-vga, x-igd-opregion > (documented in docs/igd-assign.rst with user-facing examples), > x-migration-multifd-transfer (documented in > docs/devel/vfio-migration.rst). > > - "internal compat switch to fix bug" - e.g. x-buggy-eim, > x-pci-express-writeable-slt-bug. > > These two categories have fundamentally different contracts - the > former should be settable by users, the latter should not. But today, > nothing prevents a user from writing something like: > > "-device intel-iommu,x-buggy-eim=false" > > QEMU will happily accept it. I don't see that as a bug neccessarily, but rather a feature. It has let users enable bug fixes, without changing their machine type. It has been useful when users report that a guest OS is broken after a given machine type version, to be able to toggle fixes individually. > > I don't think it does. Code evolution is painful as long as the machine > > type using the prop needs to exist with fixed semantics, whether it is > > internal or public with x- prefix. > > I agree the machine type lifetime constraint doesn't change. > > But experimental x- or normal (external) properties are by default > exposed to users, allowing them to set values via -device or other > entry points. This effectively treats the property as an API. > > Once it becomes an API, any modification to the property must consider > whether there are external dependencies. When a property is exposed with a "x-" prefix, that is saying we do *NOT* need to consider external dependencies. We can remove it at all any time, if QEMU has no internal usage left. We might *choose* to consider external usage, but that is not requird. Our only hard constraint is that the machine type version must remain with the fixed behaviour. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0

Re: [PATCH v2 00/21] qom: introduce property flags to track external user input
by BALATON Zoltan 12 Feb '26

12 Feb '26

On Wed, 11 Feb 2026, Zhao Liu wrote: >> So another way could be to not use properties for internal settings but add >> another set of internal properties for those. These could be set the same >> way but stored in a different hash table and not get mixed with >> introspectable and user changable properties. But maybe that would be too >> much refactoring. > > Yes, it may require adding interfaces similar to object_property_add/get/ > set, which would need significant changes. Maybe not that part needs significant changes as you could still use a flag the same way adding a parameter to object_property_add/get/set to tell it should put the propery in the internal hash but then you need to add the other hash and maybe related changes. I don't know how much would those be but no new interface is needed just extending existing one as you did already. Regards, BALATON Zoltan

1 0

Re: [PATCH v2 00/21] qom: introduce property flags to track external user input
by Daniel P. Berrangé 12 Feb '26

12 Feb '26

On Tue, Feb 10, 2026 at 11:28:07PM +0800, Zhao Liu wrote: > Hi Daniel, > > On Tue, Feb 10, 2026 at 10:12:38AM +0000, Daniel P. Berrangé wrote: > > Date: Tue, 10 Feb 2026 10:12:38 +0000 > > From: "Daniel P. Berrangé" <berrange(a)redhat.com> > > Subject: Re: [PATCH v2 00/21] qom: introduce property flags to track > > external user input > > > > On Tue, Feb 10, 2026 at 11:23:27AM +0800, Zhao Liu wrote: > > > Hi, > > > > > > This is the v2 trying to introduce property flags to detect user's > > > property setting (from CLI/QMP/HMP). I dropped RFC tag since previous > > > RFC v1 [1]. > > > > This says what the series is proposing, but IMHO what is more important > > here is explaining why this either desirable or appropriate to add as > > general facility in QOM. > > Yes, sorry this cover letter I wrote is overly simplified. > > This series tries to control the property access against external user. > USER_SET is the base to track external user's behavior, and DEPRECATED & > INTERNAL flags provide different levels of access control. > > Though the DEPRECATED flag does not inherently restrict access, I think > such a warning also serves as a form of control. > > The idea of restricting external access to properties is from previous > discussions [*] about internal properties. > > [*]: How to mark internal properties: > https://lore.kernel.org/qemu-devel/2f526570-7ab0-479c-967c-b3f95f9f19e3@red… > > Since that disscussion, currently all properties expected to be > "internal" have an “x-” prefix — while this approach can work, it clearly > confuses the original meaning of “x-”, which actually means "unstable". > > Therefore, I think the optimal approach is to provide the capability to > restrict external access to the property — that is, to implement the > "true" internal property. > > Based on this, it seems impossible to implement an internal property > without tracking user input in the QOM? So the main thing that pushes us into using QOM for internal properties is the machine type compatibility code. eg where we bulk set stuff using compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len); compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len); That logic is all QOM based. Using QOM isn't our exclusive approach, as we have machine types sometimes setting object fields directly. eg static void pc_i440fx_machine_7_0_options(MachineClass *m) { PCMachineClass *pcmc = PC_MACHINE_CLASS(m); pc_i440fx_machine_7_1_options(m); pcmc->enforce_amd_1tb_hole = false; compat_props_add(m->compat_props, hw_compat_7_0, hw_compat_7_0_len); compat_props_add(m->compat_props, pc_compat_7_0, pc_compat_7_0_len); } but that only works for properties against the machine type, not compat properties against devices, since we have no direct access to the other classes/instances. If we want to be able to control hardware compat, without exposing something as a user facing tunable, then internal-only QOM props seems inescapable. I do still wonder if we genuinely need internal-only QOM props for machine type compat ? Whether using a public 'x-' prefixed property or an internal only property, we're constrained by the need to retain the behaviour semantics for as long as the machine type exists. I don't see an internal only property giving us significantly more freedom here. We can already rename a 'x-' property however we want with no notice, as long as the machine type doesn't change behaviour. > > The idea that code should take different action for a given fixed value, > > based on whether the value was set by the user, or left on the default, > > makes me very uncomfortable. > > > > There have been a number of situations where something that was initially > > a boolean flag, actually needed to be a tri-state instead, to provide > > semantics like "On", "Off", "Auto". > > > > This "user set" flag could support such behaviour indirectly, but since > > "user set" is an internal concept we'd still be only exposing a boolean > > externally, while using a tri-state internally. That does not give the > > full flexibility of a tri-state, because internally if we wanted to > > have the default to be "yes", it offers no way for the mgmt app to > > put it back to "auto". > > > > For properties that are not booleans, it is much less obvious to me > > whether we actually need a distinct "not set" concept at all. > > USER_SET primarily serves the INTERNAL and DEPRECATED flags. However, > its another function is to indicates whether the external user has > touched the property. > > But, Hmm, I think "auto" and USER_SET don't have conflict? > > IIUC, "auto" means the user requests that QEMU make the decision itself. > However, just like my patch 19 cleanup of “lbr-fmt”, that property > explicitly requires users to provide a valid value. Even we have "auto" > for uint64, "auto" can't address this case. I just meant "auto" as one possible "default" behaviour where a traditional boolean was in use, not for all possible types. The right answer for a default is contextually dependent. For a uint64, a default value would involve some sentinal value, or it could involve a pair of related properties. For example, we have host-phys-bits=on phys-bits=NNN as a pair that work together, so you don't need a magic phys-bits value to represent "use host value". > Similarly, the x86 CPU's topology IDs (used for hotplug) - "thread-id"/ > "core-id"/"module-id"..., also require the user to set valid and accurate > values; they cannot be replaced with "auto". Again I wasn't suggestnig an "auto" value for every scenario, that was just an example in a "bool" context. An ID value of "0" is a traditional default for numeric values, which is fine assuming you don't need to dinstinguish 0 as a valid value, from 0 as an invalid value needing user input. > I also think the ideal situation is not to distinguish between external > and internal - however, exposing properties to external users makes code > evolution painful... I don't think it does. Code evolution is painful as long as the machine type using the prop needs to exist with fixed semantics, whether it is internal or public with x- prefix. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

1 0