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

["Cédric Le Goater" <clg@redhat.com>]

On 12/9/25 17:28, Peter Xu wrote:
> [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.

On the PPC pseries machines, we had to introduce a capability concept
and infrastructure on top of the machine versions to handle cases where
the features advertised to the guest (also visible to the OS) could
differ from one host to another and generate migration errors. See :

   hw/ppc/spapr_caps.c

These capabilities can be tweaked on the command line to adjust source
and target host support. It's mostly related to CPU and MM features.
Initially these difference were related to CPU bugs IIRC and different
FW levels on the host.

Is your proposal doing something similar ? Is my understanding correct ?

Thanks,

C.

> 
> 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 series tries to introduce a common root class OBJECT_COMPAT for it.  I
> didn't abuse OBJECT because I know there're too many OBJECTs that do not
> need compat properties at all.  With this design, we can also opt-in piece
> by piece on the new root class, only when needed.
> 
> Class OBJECT_COMPAT
> ===================
> 
> This is almost OBJECT class, except that it'll also apply machine compat
> properties from anywhere.  One can refer to patch 1.
> 
> Note that currently I didn't further identify the three possible source of
> object_compat_props[3] (accel, machine compat property, legacy globals).  I
> don't think it's a huge issue so far because non-qdev objects will not
> collapse with names in accel / legacy globals, due to the fact that object
> names cannot dup acorss QEMU binary.  So I kept the changeset as minimum as
> possible.  Feel free to shoot if there's concerns I overlooked.
> 
> This part is done in patch 1-6.  This is the part I felt slightly more
> confident with.  Meanwhile, these will be the dependency if we want to
> e.g. allow TAP network backends to take compat properties like a virtio-net
> frontend (but likely we'll need to QOMify TAP first).  That's something for
> the future even if applicable.
> 
> Export Property from QDEV
> =========================
> 
> I also have patch 7-10 below for one step further beyond OBJECT_COMPAT.
> Feel free to take it even as a seperate small series to review.
> 
> So far the first part will be the focus, but I still want to collect
> opinions here on this second part.  This is about exporting Property for
> non-qdev uses.  Currently, migration is the only user.
> 
> In short, Property is something qdev uses internally to ultimately
> represents ObjectClass's properties hash table.  It's pretty handy to
> e.g. avoid definining accessors for object properties, setting default
> values, etc.  Then they'll be converted to Object properties at some point.
> 
> Migration object currently defines all the global fields in Property and
> can use "-global migration.XXX" to allow global overrides, with almost one
> line for each property, which is efficient.
> 
> This 2nd step will allow migration object to inherit from OBJECT_COMPAT too
> with almost only a few lines of changes, and keep the functionality as-is.
> 
> Two other options we have:
> 
>    (1) Keep migration object to be a qdev, it's still fine, even if it
>        sounds hackish.. if we want to keep "-global" working as before
> 
>    (2) Inherit OBJECT_COMPAT without supporting "-global" anymore.
> 
> Any comments welcomed, especially on the first half (1-6), thanks.
> 
> Peter Xu (10):
>    qom: Introduce object-compat
>    qdev: Inherit from TYPE_OBJECT_COMPAT
>    hostmem: Inherit from TYPE_OBJECT_COMPAT
>    accel: Inherit from TYPE_OBJECT_COMPAT
>    confidential guest support: Inherit from TYPE_OBJECT_COMPAT
>    qom: Unexport object_apply_compat_props()
>    qdev: Pave way for exporting Property to be used in non-qdev
>    qdev: Introduce helper object_apply_globals()
>    qdev: Refactor and rename of qdev_class_add_property()
>    migration: Inherit from TYPE_OBJECT_COMPAT
> 
>   include/hw/qdev-properties.h          | 11 ++++++++
>   include/qom/object.h                  |  2 +-
>   migration/migration.h                 |  2 +-
>   accel/accel-common.c                  |  2 +-
>   backends/confidential-guest-support.c |  2 +-
>   backends/hostmem.c                    |  8 +-----
>   hw/core/qdev-properties.c             | 37 +++++++++++++++++++++------
>   hw/core/qdev.c                        |  6 ++---
>   migration/migration.c                 | 31 +++++++++++-----------
>   qom/object.c                          | 16 +++++++++++-
>   system/vl.c                           |  1 -
>   target/i386/sev.c                     |  1 -
>   12 files changed, 79 insertions(+), 40 deletions(-)
>