Re: [PATCH RFC 00/10] QOM: Introduce OBJECT_COMPAT class

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

On Wed, Dec 10, 2025 at 11:17:43AM -0500, Peter Xu wrote:
> Maybe I emphasized too much on "guest ABI" in the cover letter, so it can
> be confusing when not reading into the details of the patchset (I did
> mention all the existing users in patch 1, then converted all existing
> users in patch 2-5).
> 
> Besides SEV, I can also quickly go over the rest ones if that wasn't clear
> we're already using this feature.. in a open-coded way.  Maybe that'll make
> it slightly easier to grasp for reviewers.
> 
> The current use case for hostmem (2nd example) on compat properties, see:
> 
>     commit fa0cb34d2210cc749b9a70db99bb41c56ad20831
>     Author: Marc-André Lureau <marcandre.lureau@redhat.com>
>     Date:   Wed Sep 12 16:18:00 2018 +0400
> 
>     hostmem: use object id for memory region name with >= 4.0
> 
> So that's not strictly "guest ABI", but the goal was to persist the name of
> MRs so that migration is not broken.  It's not strictly "guest ABI" but
> more like "guest ABI for migration" - even if the guest OS cannot see the
> names of MRs, migration can see (via ramblocks).  So it can be more than
> the guest HWs.

I'm more amenable to this example being in scope of machine types. The
most important use case for machine types, by a mile, is to ensure that
live migration works between 2 QEMUs. Having a stable guest ABI does
have other use cases like ensuring Windows doesn't trigger license
(re-)activation, but live migration is the important one. It is
unfortunate that the object id leaked into the migration stream but
this was a reasonable (hack) workaround to address it.


> 3rd example in accel:
> 
>     commit fe174132478b4e7b0086f2305a511fd94c9aca8b
>     Author: Paolo Bonzini <pbonzini@redhat.com>
>     Date:   Wed Nov 13 15:16:44 2019 +0100
> 
>     tcg: add "-accel tcg,tb-size" and deprecate "-tb-size"
> 
> That was trying to keep some old behavior for accel cmdlines.  It's not
> even a migration ABI, but cmdline ABI.
>
> Hence OBJECT_COMPAT might be useful whenever we want to persist some ABI.
> It can be machine compat properties, it can be something else that has
> nothing to do with machine types.  The accel example used a separate entry
> in object_compat_props[] (index 0) for the same purpose, out of three:

Ok, yes, this compat props usage that's independent of machine
type is fine.

> 
> /*
>  * Global property defaults
>  * Slot 0: accelerator's global property defaults
>  * Slot 1: machine's global property defaults
>  * Slot 2: global properties from legacy command line option
>  * Each is a GPtrArray of GlobalProperty.
>  * Applied in order, later entries override earlier ones.
>  */
> static GPtrArray *object_compat_props[3];

> > I've suggested in the past that IMHO we're missing a concept of a
> > "versioned platform", to complement the "versioned machine" concept.
> > 
> > That would let mgmt apps decide what platform compatibility level
> > they required, independantly of choosing machine types, and so avoid
> > creating runability constraints on machine types.
> 
> Yes, I agree some kind of "versioned platform" would be nice.  In practise,
> I wonder if it needs to be versioned at all, or something like a
> query-platform QMP API that will return the capabilities of the host in
> QEMU's view.  Maybe versioning isn't needed here.
> 
> Taking USO* feature for virtio-net as example, it should report what kind
> of USO* features are supported on this host.

The appealing thing about machine types is that it is an opaque
collection of properties. The mgmt app does not need to know about
any of the properties being set, it can just let the machine type
do its magic.

Probing values for individual features which are supported on a host
means mgmt apps need to be made aware of all the properties that are
affected, and keep track of them for the life of the VM. This is a
significantly higher burden for the mgmt app to deal with that the
opaque collection machine types define, especially because apps won't
know ahead of time which objects/properties might need this facility
in future.

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