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

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

On Wed, Dec 10, 2025 at 12:27:30PM +0100, Kevin Wolf wrote:
> Am 09.12.2025 um 17:28 hat Peter Xu geschrieben:
> > [This is an RFC series, as being marked out.  It is trying to collect
> >  opinions.  It's not for merging yet]
> > 
> > Background
> > ==========
> > 
> > It all starts with machine compat properties..
> > 
> > Machine compat properties are the major weapon we use currently in QEMU to
> > define a proper guest ABI, so that whenever we migration a VM instance from
> > whatever QEMU version1 to another QEMU version2, as long as the machine
> > type is the same, logically the ABI is guaranteed, and migration should
> > succeed.  If it didn't, it's a bug.
> > 
> > These compat properties are only attached to qdev for now.  It almost
> > worked.
> > 
> > Said that, it's also not true - we already have non-qdev users of such, by
> > explicitly code it up to apply the compat fields.  Please refer to the
> > first patch commit message for details (meanwhile latter patches will
> > convert them into a generic model).
> > 
> > Obviously, we have demands to leverage machine compat properties even
> > outside of qdev.  It can be a network backend, it can be an object (for
> > example, memory backends), it can be a migration object, and more.
> 
> This doesn't feel obvious to me at all. A machine type defines what
> hardware the guest sees. Guest hardware is essentially qdev.
> 
> I don't see any reasons why a backend should be interested in what guest
> hardware looks like, that would seem like a bad layering violation. Many
> backends can even exist without a guest at all, and are also used in
> tools like qemu-storage-daemon. Having a machine type in a tool that
> doesn't run a guest doesn't make any sense.

The sev-guest compat property for 'legacy-vm-type' is an interesting
example.

This property ultimately controls which of two different kernel ioctls
for KVM are used for initializing the SEV guest. It can casue guest
VM measurement changes, but none the less this is not really a guest
ABI knob, it is a host kernel compatibility knob.  You need a newer
host kernel version if this is set to 'off'.

So by associating this legacy-vm-type type with the machine type,
we don't affect the guest hardware, but we *do* impact the ability
to use that machine type depedning on what kernel version you have.

IOW, QEMU machine types version 9.1 or later are no longer runnable
on many old kernels.

Over the years we've had a good number of occassions where we want
defaults changes, or worse, where we auto-negotiate features, which
depend on host kernel version.

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.

> So if we do introduce some mechanism to provide different defaults for
> compatibility with older versions, it has to be separate from machine
> types.
> 
> Maybe it would make most sense to address this on the QAPI level then
> and finally fully QAPIfy the command line. Adding defaults to the QAPI
> schema is something that has come up again and again, so maybe we could
> introduce that and do it in a versioned way from the start.


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