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

[Peter Xu <peterx@redhat.com>]

On Thu, Dec 11, 2025 at 03:26:13PM +0000, Daniel P. Berrangé wrote:
> On Thu, Dec 11, 2025 at 10:09:16AM -0500, Peter Xu wrote:
> > On Thu, Dec 11, 2025 at 09:48:32AM +0000, Daniel P. Berrangé wrote:
> > > 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.
> > 
> > Yes, exactly.
> > 
> > IMHO we may still need "probing" of host features at some point, but we do
> > have two completely different way to stable the guest ABI:
> > 
> >   (a) Machine types (like now)
> >   (b) "probing" + "QMP set()s"
> > 
> > Here "QMP set()s" can be QMP updating a property of an object, or something
> > like what Vladimir proposed in the other virtio-net/tap series, via a
> > separate new QMP command.
> > 
> > Solution (b) has a major benefit of high flexibility - we do not need
> > machine type versioning anymore (hence, we still need "q35", but not
> > "q35-X.Y" etc.), because any QEMU can likely migrate to almost any QEMU:
> > mgmt will probe both sides and apply mini subset for both sides, no matter
> > how old it was.
> > 
> > To pay that off, mgmt needs to know every single trivial detail of QEMU
> > change on every single device to make migration work.  When new things
> > introduced to QEMU, it must be OFF, then mgmt turns it on until probing
> > both sides have it.
> > 
> > That makes solution (b) less appealing.
> > 
> > The other thing is, since we stick with solution (a) for all these years,
> > IMHO we should either stick with it, or if we really think (b) is better we
> > should gradually obsolete (a) and use (b) all over.  I just don't see it
> > coming, though.. as (a) is still working almost perfect - it enables
> > feature slower only until a new machine type used (normally means a VM cold
> > reboot), but it hides too many trivial details mgmt doesn't need to care,
> > hence much less work needed.
> > 
> > IMHO we should be careful on making both (a)+(b) available (again, for (b)
> > the probing is still fine, it's about offloading things to mgmt to set()
> > via QMPs).  If so, it likely implies we didn't think all things through.
> 
> I don't believe that probing could ever be a placement for (a). Determining
> what you want to use is not a decision that can be made in isolation of
> the current host. You need to know the capabilities of hosts that you
> intend to be able to migrate to.
> 
> Machine type versions facilitate this as an admin can express the
> compatibility constraint in terms of this high level opaque definition,
> and not have to understand 100's of properties and their supportability
> across many hosts.
> 
> The same applies to non-guest host compatibility settings. I might be
> runing on a RHEL-9.6 host, but I want to have compatibility with any
> RHEL-9.2 host or newer. I can't probe QEMU on the 9.6 host to determine
> what is acceptable for 9.2. We need to be able to express that cross
> host compatibility as an admin, without having to list a huge set of
> individual properties.

Yes, maybe I didn't explain myself clearly, I believe we share the view.

My point was we shouldn't introduce special QMP commands to do set()s just
to work similiarly as what machine versioning / compat properties do.

I hope we will start to have something like query-platform soon.  Jason and
Michael have some discussion here, which should be discussing similar
concept:

https://lore.kernel.org/all/CACGkMEtdxWJygVbcuvER5yj13R0JL_bxPSAg0eYyiBeh=SyRXg@mail.gmail.com/

Maybe USO can be a start point for us doing this, allowing mgmt to probe
host features.

Thanks,

-- 
Peter Xu