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

[Peter Xu <peterx@redhat.com>]

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.

Thanks,

-- 
Peter Xu