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