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 :|