Re: [PATCH v2 00/21] qom: introduce property flags to track external user input

["Daniel P. Berrangé" <berrange@redhat.com>]

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