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

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

[Peter Xu]

[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 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(-)

-- 
2.50.1

[PATCH RFC 01/10] qom: Introduce object-compat

[Peter Xu]

QEMU provides machine compat properties so that old machine types can
define device properties, which will be compatible with old QEMU binaris.

This is the core of how QEMU manages VM ABI across migrations between
different versions of QEMUs.

It used to almost only work for qdev, which was almost enough.  There were
already outliers showed up:

  - do_configure_accelerator()
  - host_memory_backend_post_init()
  - sev_guest_instance_init()

They all invoke object_apply_compat_props() explicitly, because they want
to benefit from the machine compat properties too, just like normal qdevs.
However they're not qdev, hence they need explicit code to support it.

MigrationState object is another example that wants to use similar feature
of qdev.  That was previously done by making TYPE_MIGRATION inherit
TYPE_DEVICE.  See comments for migration_type.  That's working but weird,
e.g. people may question what "-device migration" means..

Nowadays, there're more demands of that, e.g., what if we want to allow
compat properties to be applied to device backends ([1,2])?

Maybe it's time to think about extending the compat properties to a root
class so that more objects can inherit.

This patch introduces object-compat, which is almost object except that it
also allows apply machine compat properties on top.  Then any object that
is not qdev but wants to benefit from machine compat properties can opt-in.

[1] https://lore.kernel.org/r/20251030203116.870742-1-vsementsov@yandex-team.ru
[2] https://lore.kernel.org/r/d986f0ac-a0ae-44f6-b7a5-e002b7d3226e@yandex-team.ru

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 include/qom/object.h |  1 +
 qom/object.c         | 14 ++++++++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/qom/object.h b/include/qom/object.h
index 26df6137b9..e5b3116ad5 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -26,6 +26,7 @@ typedef struct InterfaceClass InterfaceClass;
 typedef struct InterfaceInfo InterfaceInfo;
 
 #define TYPE_OBJECT "object"
+#define TYPE_OBJECT_COMPAT "object-compat"
 #define TYPE_CONTAINER "container"
 
 typedef struct ObjectProperty ObjectProperty;
diff --git a/qom/object.c b/qom/object.c
index 4f32c1aba7..581c041b08 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -2893,6 +2893,11 @@ void object_class_property_set_description(ObjectClass *klass,
     op->description = g_strdup(description);
 }
 
+static void object_compat_post_init(Object *obj)
+{
+    object_apply_compat_props(obj);
+}
+
 static void object_class_init(ObjectClass *klass, const void *data)
 {
     object_class_property_add_str(klass, "type", object_get_type,
@@ -2914,8 +2919,17 @@ static void register_types(void)
         .abstract = true,
     };
 
+    static const TypeInfo object_compat_info = {
+        .parent = TYPE_OBJECT,
+        .name = TYPE_OBJECT_COMPAT,
+        .instance_size = sizeof(Object),
+        .instance_post_init = object_compat_post_init,
+        .abstract = true,
+    };
+
     type_interface = type_register_internal(&interface_info);
     type_register_internal(&object_info);
+    type_register_internal(&object_compat_info);
 }
 
 type_init(register_types)
-- 
2.50.1

[PATCH RFC 02/10] qdev: Inherit from TYPE_OBJECT_COMPAT

[Peter Xu]

Make qdev inherit from TYPE_OBJECT_COMPAT, so it's own instance_post_init()
only needs to apply the global properties instead.  Order kept because we
run post hooks in parents then children.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 hw/core/qdev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index fab42a7270..49504ff05a 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -683,9 +683,9 @@ static void device_post_init(Object *obj)
 {
     /*
      * Note: ordered so that the user's global properties take
-     * precedence.
+     * precedence over compat properties.  Compat-properties will be
+     * applied first in the parent class (TYPE_OBJECT_COMPAT).
      */
-    object_apply_compat_props(obj);
     qdev_prop_set_globals(DEVICE(obj));
 }
 
@@ -890,7 +890,7 @@ void phase_advance(MachineInitPhase phase)
 
 static const TypeInfo device_type_info = {
     .name = TYPE_DEVICE,
-    .parent = TYPE_OBJECT,
+    .parent = TYPE_OBJECT_COMPAT,
     .instance_size = sizeof(DeviceState),
     .instance_init = device_initfn,
     .instance_post_init = device_post_init,
-- 
2.50.1

[PATCH RFC 03/10] hostmem: Inherit from TYPE_OBJECT_COMPAT

[Peter Xu]

With that, now it can drop its own post_init hook.

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 backends/hostmem.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/backends/hostmem.c b/backends/hostmem.c
index 35734d6f4d..7d726bfb49 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -293,11 +293,6 @@ static void host_memory_backend_init(Object *obj)
     backend->prealloc_threads = machine->smp.cpus;
 }
 
-static void host_memory_backend_post_init(Object *obj)
-{
-    object_apply_compat_props(obj);
-}
-
 bool host_memory_backend_mr_inited(HostMemoryBackend *backend)
 {
     /*
@@ -579,13 +574,12 @@ host_memory_backend_class_init(ObjectClass *oc, const void *data)
 
 static const TypeInfo host_memory_backend_info = {
     .name = TYPE_MEMORY_BACKEND,
-    .parent = TYPE_OBJECT,
+    .parent = TYPE_OBJECT_COMPAT,
     .abstract = true,
     .class_size = sizeof(HostMemoryBackendClass),
     .class_init = host_memory_backend_class_init,
     .instance_size = sizeof(HostMemoryBackend),
     .instance_init = host_memory_backend_init,
-    .instance_post_init = host_memory_backend_post_init,
     .interfaces = (const InterfaceInfo[]) {
         { TYPE_USER_CREATABLE },
         { }
-- 
2.50.1

[PATCH RFC 04/10] accel: Inherit from TYPE_OBJECT_COMPAT

[Peter Xu]

With it, remove the explicit call to apply compat properties.

Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 accel/accel-common.c | 2 +-
 system/vl.c          | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/accel/accel-common.c b/accel/accel-common.c
index 850c5ab4b8..b08eba35cd 100644
--- a/accel/accel-common.c
+++ b/accel/accel-common.c
@@ -134,7 +134,7 @@ int accel_supported_gdbstub_sstep_flags(void)
 static const TypeInfo accel_types[] = {
     {
         .name           = TYPE_ACCEL,
-        .parent         = TYPE_OBJECT,
+        .parent         = TYPE_OBJECT_COMPAT,
         .class_size     = sizeof(AccelClass),
         .instance_size  = sizeof(AccelState),
         .abstract       = true,
diff --git a/system/vl.c b/system/vl.c
index 5091fe52d9..a93201ef53 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -2404,7 +2404,6 @@ static int do_configure_accelerator(void *opaque, QemuOpts *opts, Error **errp)
         goto bad;
     }
     accel = ACCEL(object_new_with_class(OBJECT_CLASS(ac)));
-    object_apply_compat_props(OBJECT(accel));
     qemu_opt_foreach(opts, accelerator_set_property,
                      accel,
                      &error_fatal);
-- 
2.50.1

[PATCH RFC 05/10] confidential guest support: Inherit from TYPE_OBJECT_COMPAT

[Peter Xu]

Currently, only SEV uses it, but it shouldn't hurt either to make the root
class (CONFIDENTIAL_GUEST_SUPPORT) to inherit from TYPE_OBJECT_COMPAT, so
that it'll apply compat properties when object is initialized.  With it,
drop the explicit call.

Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Michael Roth <michael.roth@amd.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
---
 backends/confidential-guest-support.c | 2 +-
 target/i386/sev.c                     | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/backends/confidential-guest-support.c b/backends/confidential-guest-support.c
index 156dd15e66..855788fac0 100644
--- a/backends/confidential-guest-support.c
+++ b/backends/confidential-guest-support.c
@@ -19,7 +19,7 @@
 OBJECT_DEFINE_ABSTRACT_TYPE(ConfidentialGuestSupport,
                             confidential_guest_support,
                             CONFIDENTIAL_GUEST_SUPPORT,
-                            OBJECT)
+                            OBJECT_COMPAT)
 
 static bool check_support(ConfidentialGuestPlatformType platform,
                          uint16_t platform_version, uint8_t highest_vtl,
diff --git a/target/i386/sev.c b/target/i386/sev.c
index fd2dada013..084264bc88 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -2865,7 +2865,6 @@ sev_guest_instance_init(Object *obj)
                                    OBJ_PROP_FLAG_READWRITE);
     object_property_add_uint32_ptr(obj, "policy", &sev_guest->policy,
                                    OBJ_PROP_FLAG_READWRITE);
-    object_apply_compat_props(obj);
 
     sev_guest->legacy_vm_type = ON_OFF_AUTO_AUTO;
 }
-- 
2.50.1

[PATCH RFC 06/10] qom: Unexport object_apply_compat_props()

[Peter Xu]

Now all users switched to TYPE_OBJECT_COMPAT, we do not need to export this
function anymore.  Instead, future objects should inherit from
TYPE_OBJECT_COMPAT when compat properties are needed.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 include/qom/object.h | 1 -
 qom/object.c         | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index e5b3116ad5..6c7b8fdab1 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -707,7 +707,6 @@ void object_set_machine_compat_props(GPtrArray *compat_props);
 void object_set_accelerator_compat_props(GPtrArray *compat_props);
 void object_register_sugar_prop(const char *driver, const char *prop,
                                 const char *value, bool optional);
-void object_apply_compat_props(Object *obj);
 
 /**
  * object_set_props:
diff --git a/qom/object.c b/qom/object.c
index 581c041b08..176b859f36 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -530,7 +530,7 @@ void object_set_accelerator_compat_props(GPtrArray *compat_props)
     object_compat_props[0] = compat_props;
 }
 
-void object_apply_compat_props(Object *obj)
+static void object_apply_compat_props(Object *obj)
 {
     int i;
 
-- 
2.50.1

[PATCH RFC 07/10] qdev: Pave way for exporting Property to be used in non-qdev

[Peter Xu]

Property itself is a well defined interface to either support smooth
conversions to Object's properties, or supports global properties.  However
currently it's tied to DeviceClass, aka, qdev. So non-qdev cannot use
Property list.

My current observation shows Property is almost ready to be used as a
separated exported interface, except two small things that may need touch
up internally:

        qdev_prop_allow_set
        qdev_prop_check_globals

The 1st one currently checks against realize state (which is part of qdev
attributes only).  The 2nd one checks for all global property being used in
all non-pluggable qdevs.

We can loose the check in both spots, keep the check if the driver is a
qdev, otherwise we can safely whitelist non-qdev use cases of Property.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 hw/core/qdev-properties.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 422a486969..c8110ff0b8 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -30,8 +30,14 @@ void qdev_prop_set_after_realize(DeviceState *dev, const char *name,
 static bool qdev_prop_allow_set(Object *obj, const char *name,
                                 const PropertyInfo *info, Error **errp)
 {
-    DeviceState *dev = DEVICE(obj);
+    DeviceState *dev;
+
+    if (!object_dynamic_cast(obj, TYPE_DEVICE)) {
+        /* Currently, non-qdev can always set Property anytime */
+        return true;
+    }
 
+    dev = DEVICE(obj);
     if (dev->realized && !info->realized_set_allowed) {
         qdev_prop_set_after_realize(dev, name, errp);
         return false;
@@ -987,6 +993,7 @@ int qdev_prop_check_globals(void)
 
     for (i = 0; i < global_props()->len; i++) {
         GlobalProperty *prop;
+        bool hotpluggable;
         ObjectClass *oc;
         DeviceClass *dc;
 
@@ -995,15 +1002,25 @@ int qdev_prop_check_globals(void)
             continue;
         }
         oc = object_class_by_name(prop->driver);
-        oc = object_class_dynamic_cast(oc, TYPE_DEVICE);
+        oc = object_class_dynamic_cast(oc, TYPE_OBJECT_COMPAT);
         if (!oc) {
             warn_report("global %s.%s has invalid class name",
                         prop->driver, prop->property);
             ret = 1;
             continue;
         }
-        dc = DEVICE_CLASS(oc);
-        if (!dc->hotpluggable && !prop->used) {
+        oc = object_class_dynamic_cast(oc, TYPE_DEVICE);
+        if (oc) {
+            dc = DEVICE_CLASS(oc);
+            hotpluggable = dc->hotpluggable;
+        } else {
+            /*
+             * Currently, to be strict to assume all non-qdev are not
+             * hotpluggable (whoever will use -global).
+             */
+            hotpluggable = false;
+        }
+        if (!hotpluggable && !prop->used) {
             warn_report("global %s.%s=%s not used",
                         prop->driver, prop->property, prop->value);
             ret = 1;
-- 
2.50.1

[PATCH RFC 08/10] qdev: Introduce helper object_apply_globals()

[Peter Xu]

The helper allows one object to apply anything from -global command lines
to an object.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 include/hw/qdev-properties.h | 1 +
 hw/core/qdev-properties.c    | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index 60b8133009..f064992ba3 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -226,6 +226,7 @@ const GlobalProperty *qdev_find_global_prop(Object *obj,
                                             const char *name);
 int qdev_prop_check_globals(void);
 void qdev_prop_set_globals(DeviceState *dev);
+void object_apply_globals(Object *obj);
 void error_set_from_qdev_prop_error(Error **errp, int ret, Object *obj,
                                     const char *name, const char *value);
 
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index c8110ff0b8..7d1a443266 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -1036,6 +1036,11 @@ void qdev_prop_set_globals(DeviceState *dev)
                               dev->hotplugged ? NULL : &error_fatal);
 }
 
+void object_apply_globals(Object *obj)
+{
+    object_apply_global_props(obj, global_props(), &error_fatal);
+}
+
 /* --- 64bit unsigned int 'size' type --- */
 
 static void get_size(Object *obj, Visitor *v, const char *name, void *opaque,
-- 
2.50.1

[PATCH RFC 09/10] qdev: Refactor and rename of qdev_class_add_property()

[Peter Xu]

Firstly, qdev_class_add_property() function almost has nothing to do with
DeviceClass, it's a bridge between Property and object properties.

Change the 1st parameter of it, so that it can be used without DeviceClass
context at all. When at it, remove the "name" field because it's always
prop->name.

Export it for non-qdev use cases.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 include/hw/qdev-properties.h | 10 ++++++++++
 hw/core/qdev-properties.c    |  7 +++----
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/include/hw/qdev-properties.h b/include/hw/qdev-properties.h
index f064992ba3..bf90cac810 100644
--- a/include/hw/qdev-properties.h
+++ b/include/hw/qdev-properties.h
@@ -241,6 +241,16 @@ void error_set_from_qdev_prop_error(Error **errp, int ret, Object *obj,
  */
 void qdev_property_add_static(DeviceState *dev, const Property *prop);
 
+/**
+ * object_class_add_property:
+ * @oc: Object class to operate on.
+ * @prop: The qdev property definition.
+ *
+ * Add a Property to @oc.  This is the bridge to convert a Property into
+ * an object class property (as in ObjectClass.properties).
+ */
+void object_class_add_property(ObjectClass *oc, const Property *prop);
+
 /**
  * qdev_alias_all_properties: Create aliases on source for all target properties
  * @target: Device which has properties to be aliased
diff --git a/hw/core/qdev-properties.c b/hw/core/qdev-properties.c
index 7d1a443266..ede173d57b 100644
--- a/hw/core/qdev-properties.c
+++ b/hw/core/qdev-properties.c
@@ -1108,10 +1108,9 @@ void qdev_property_add_static(DeviceState *dev, const Property *prop)
     }
 }
 
-static void qdev_class_add_property(DeviceClass *klass, const char *name,
-                                    const Property *prop)
+void object_class_add_property(ObjectClass *oc, const Property *prop)
 {
-    ObjectClass *oc = OBJECT_CLASS(klass);
+    const char *name = prop->name;
     ObjectProperty *op;
 
     if (prop->info->create) {
@@ -1188,7 +1187,7 @@ void device_class_set_props_n(DeviceClass *dc, const Property *props, size_t n)
         const Property *prop = &props[i];
         assert(prop->name);
         qdev_class_add_legacy_property(dc, prop);
-        qdev_class_add_property(dc, prop->name, prop);
+        object_class_add_property(OBJECT_CLASS(dc), prop);
     }
 }
 
-- 
2.50.1

[PATCH RFC 10/10] migration: Inherit from TYPE_OBJECT_COMPAT

[Peter Xu]

While doing that, we still want to keep the Property list that migration
object used to use.  Apply them directly to ObjectClass instead of setting
them with a DeviceClass.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 migration/migration.h |  2 +-
 migration/migration.c | 31 ++++++++++++++++---------------
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/migration/migration.h b/migration/migration.h
index 213b33fe6e..20a76664df 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -273,7 +273,7 @@ struct MigrationClass {
 
 struct MigrationState {
     /*< private >*/
-    DeviceState parent_obj;
+    Object parent_obj;
 
     /*< public >*/
     QemuThread thread;
diff --git a/migration/migration.c b/migration/migration.c
index b316ee01ab..913c005bcb 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -4136,11 +4136,9 @@ fail:
 
 static void migration_class_init(ObjectClass *klass, const void *data)
 {
-    DeviceClass *dc = DEVICE_CLASS(klass);
-
-    dc->user_creatable = false;
-    device_class_set_props_n(dc, migration_properties,
-                             migration_properties_count);
+    for (int i = 0; i < migration_properties_count; i++) {
+        object_class_add_property(klass, &migration_properties[i]);
+    }
 }
 
 static void migration_instance_finalize(Object *obj)
@@ -4198,21 +4196,24 @@ static bool migration_object_check(MigrationState *ms, Error **errp)
     return migrate_caps_check(old_caps, ms->capabilities, errp);
 }
 
-static const TypeInfo migration_type = {
-    .name = TYPE_MIGRATION,
+static void migration_instance_post_init(Object *obj)
+{
     /*
-     * NOTE: TYPE_MIGRATION is not really a device, as the object is
-     * not created using qdev_new(), it is not attached to the qdev
-     * device tree, and it is never realized.
-     *
-     * TODO: Make this TYPE_OBJECT once QOM provides something like
-     * TYPE_DEVICE's "-global" properties.
+     * Note: ordered so that the user's global properties take
+     * precedence over compat properties.  Compat-properties will be
+     * applied first in the parent class (TYPE_OBJECT_COMPAT).
      */
-    .parent = TYPE_DEVICE,
+    object_apply_globals(obj);
+}
+
+static const TypeInfo migration_type = {
+    .name = TYPE_MIGRATION,
+    .parent = TYPE_OBJECT_COMPAT,
     .class_init = migration_class_init,
-    .class_size = sizeof(MigrationClass),
+    .class_size = sizeof(ObjectClass),
     .instance_size = sizeof(MigrationState),
     .instance_init = migration_instance_init,
+    .instance_post_init = migration_instance_post_init,
     .instance_finalize = migration_instance_finalize,
 };
 
-- 
2.50.1

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

[Kevin Wolf]

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.

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.

Kevin

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

[Daniel P. Berrangé]

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

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

[Peter Xu]

On Wed, Dec 10, 2025 at 11:52:04AM +0000, Daniel P. Berrangé wrote:
> 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.

Yes.

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.

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:

/*
 * 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];

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

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.

IMHO it doesn't need to be the "yet another" weapon to define guest ABI /
QEMU ABI.

Mgmt should leverage that interface to query and get platform informations
across the whole cluster, then find a minimum set. Maybe also plus
something the user would specify, for example, an user may want to
explicitly disable USO feature on the whole cluster, then mgmt should also
take it into account.

After the min subset of platform features selected, mgmt will need to map
them into device properties and apply then when booting VM.  Then guest ABI
is guaranteed.

So I think it might still be good we stick with the solo way to define the
ABI, I hope we can stick with machine types.

There're also other things that may not be attached to platform
capabilities, like the current discussion in:

https://lore.kernel.org/all/20251030203116.870742-1-vsementsov@yandex-team.ru/

That is about some new capability of network backend (in this case, TAP)
that we should always enable for new QEMUs, but disable for old QEMUs.
Such won't appear at all in query-platform..  Current solution proposed in
that series was adding per-device special QMP commands to query and set
these features.  However IMHO essentially it's the same problem that
object_compat_props() is solving.  It's just that we need it to work
outside of QDEV.

With OBJECT_COMPAT, we could QOMify TAP into an object and inherit from
OBJECT_COMPAT.

Thanks,

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

-- 
Peter Xu

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

[Vladimir Sementsov-Ogievskiy]

On 10.12.25 19:17, Peter Xu wrote:
> On Wed, Dec 10, 2025 at 11:52:04AM +0000, Daniel P. Berrangé wrote:
>> 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.
> 
> Yes.
> 
> 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.
> 
> 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:
> 
> /*
>   * 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];
> 
>>
>> 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.
> 
> 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.
> 
> IMHO it doesn't need to be the "yet another" weapon to define guest ABI /
> QEMU ABI.
> 
> Mgmt should leverage that interface to query and get platform informations
> across the whole cluster, then find a minimum set. Maybe also plus
> something the user would specify, for example, an user may want to
> explicitly disable USO feature on the whole cluster, then mgmt should also
> take it into account.
> 
> After the min subset of platform features selected, mgmt will need to map
> them into device properties and apply then when booting VM.  Then guest ABI
> is guaranteed.
> 
> So I think it might still be good we stick with the solo way to define the
> ABI, I hope we can stick with machine types.
> 
> There're also other things that may not be attached to platform
> capabilities, like the current discussion in:
> 
> https://lore.kernel.org/all/20251030203116.870742-1-vsementsov@yandex-team.ru/
> 
> That is about some new capability of network backend (in this case, TAP)
> that we should always enable for new QEMUs, but disable for old QEMUs.
> Such won't appear at all in query-platform..  Current solution proposed in
> that series was adding per-device special QMP commands to query and set
> these features.  However IMHO essentially it's the same problem that
> object_compat_props() is solving.  It's just that we need it to work
> outside of QDEV.
> 
> With OBJECT_COMPAT, we could QOMify TAP into an object and inherit from
> OBJECT_COMPAT.
> 
> Thanks,
> 

My two cents.

1. QAPI vs QOM

First, QEMU has too many object-like interfaces: QOM, QAPI structures, vmstates..
Of course, it would be better to have one generic. Should it be QAPI or QOBJECT?

If I understand correctly, these series expand the QOBJECTS's zone of influence. And
Kevin argue, that it could be QAPI instead. Right?

QOBJECT is better in a way that it represent existing in-QEMU state. QAPI structures
are normally used only temporarily during QMP calls.

If everything was a QOBJECT, we probably should not have to invent all these -replace-
and -change- commands in QMP for block layer object, but only implement set/get for
corresponding QOBJECT properties. And we'd not have to unite the namespaces of
qom paths, block export names and block node names, they all would be qom paths..

So we could live in the world, where we need to implement only "action" QMP commands,
like "migrate", "quit", "cont". But to change/query the state, we always use qom-set
qom-get, and don't invent a new command for each piece of state.

On the other hand, QAPI is a lot better in a way that it have explicit json schema.
QAPI definition is a protocol specification in the same time, we don't have such
thing for QOM. Probably the best world would be a QAPI-like interface to internal
QEMU objects, which are defined by QAPI structures. A kind of combination of best
options of QOM and QAPI worlds. But that's only a dream.


2. Machine types

I'd not care about them too much. Machine type is a syntax sugar, it's simply a
"set of defaults".

So, I think it's OK to share the concept wider than guest-ABI. What's wrong if
we just rename "Machine Type" into "Set Of QOM Defaults", and follow Peter's
suggestion? This way it will not conflict with tools that doesn't start the
guest, or don't have frontends.


-- 
Best regards,
Vladimir

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

[Peter Xu]

On Wed, Dec 10, 2025 at 09:25:16PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 10.12.25 19:17, Peter Xu wrote:
> > On Wed, Dec 10, 2025 at 11:52:04AM +0000, Daniel P. Berrangé wrote:
> > > 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.
> > 
> > Yes.
> > 
> > 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.
> > 
> > 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:
> > 
> > /*
> >   * 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];

[1]

> > 
> > > 
> > > 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.
> > 
> > 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.
> > 
> > IMHO it doesn't need to be the "yet another" weapon to define guest ABI /
> > QEMU ABI.
> > 
> > Mgmt should leverage that interface to query and get platform informations
> > across the whole cluster, then find a minimum set. Maybe also plus
> > something the user would specify, for example, an user may want to
> > explicitly disable USO feature on the whole cluster, then mgmt should also
> > take it into account.
> > 
> > After the min subset of platform features selected, mgmt will need to map
> > them into device properties and apply then when booting VM.  Then guest ABI
> > is guaranteed.
> > 
> > So I think it might still be good we stick with the solo way to define the
> > ABI, I hope we can stick with machine types.
> > 
> > There're also other things that may not be attached to platform
> > capabilities, like the current discussion in:
> > 
> > https://lore.kernel.org/all/20251030203116.870742-1-vsementsov@yandex-team.ru/
> > 
> > That is about some new capability of network backend (in this case, TAP)
> > that we should always enable for new QEMUs, but disable for old QEMUs.
> > Such won't appear at all in query-platform..  Current solution proposed in
> > that series was adding per-device special QMP commands to query and set
> > these features.  However IMHO essentially it's the same problem that
> > object_compat_props() is solving.  It's just that we need it to work
> > outside of QDEV.
> > 
> > With OBJECT_COMPAT, we could QOMify TAP into an object and inherit from
> > OBJECT_COMPAT.
> > 
> > Thanks,
> > 
> 
> My two cents.
> 
> 1. QAPI vs QOM
> 
> First, QEMU has too many object-like interfaces: QOM, QAPI structures, vmstates..
> Of course, it would be better to have one generic. Should it be QAPI or QOBJECT?

Just to make sure we're on the same page - this series didn't introduce any
new concept.  Patch 1-6 can be seen as a "cleanup" because we already use
object compat properties before.

It was explicitly coded though to invoke object_apply_compat_props() in
whatever objects that care about it.  This "cleanup" introduced another
class so that explicit call (in most cases, post_init hook) can be avoided.

Side benefit is, anything else can start to inherit from OBJECT_COMPAT now
even if not a qdev, with no further open-coded invocations.

I need to confess I don't fully get how this can be defined in QAPI,
however no matter how it can be defined, we already have the QOBJECT
solution..  Some elaboration on that part would be helpful.

> 
> If I understand correctly, these series expand the QOBJECTS's zone of influence. And
> Kevin argue, that it could be QAPI instead. Right?
> 
> QOBJECT is better in a way that it represent existing in-QEMU state. QAPI structures
> are normally used only temporarily during QMP calls.
> 
> If everything was a QOBJECT, we probably should not have to invent all these -replace-
> and -change- commands in QMP for block layer object, but only implement set/get for
> corresponding QOBJECT properties. And we'd not have to unite the namespaces of
> qom paths, block export names and block node names, they all would be qom paths..
> 
> So we could live in the world, where we need to implement only "action" QMP commands,
> like "migrate", "quit", "cont". But to change/query the state, we always use qom-set
> qom-get, and don't invent a new command for each piece of state.
> 
> On the other hand, QAPI is a lot better in a way that it have explicit json schema.
> QAPI definition is a protocol specification in the same time, we don't have such
> thing for QOM. Probably the best world would be a QAPI-like interface to internal
> QEMU objects, which are defined by QAPI structures. A kind of combination of best
> options of QOM and QAPI worlds. But that's only a dream.

This part of discussion seems to have some block layer internals involved
that I'm not familiar with.  I'm not sure I get it, but I'll leave others
to chime in..

> 
> 2. Machine types
> 
> I'd not care about them too much. Machine type is a syntax sugar, it's simply a
> "set of defaults".
> 
> So, I think it's OK to share the concept wider than guest-ABI. What's wrong if
> we just rename "Machine Type" into "Set Of QOM Defaults", and follow Peter's
> suggestion? This way it will not conflict with tools that doesn't start the
> guest, or don't have frontends.

Yes, it's not only about machine types.  Per discussed above [1], literally
it was called object_compat_props[].

An object applies it with object_apply_compat_props().  Machine type is
only using index 1, and it's only one user of compat properties, only that
it's the major user.

Thanks,

-- 
Peter Xu

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

[Daniel P. Berrangé]

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

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

[Peter Xu]

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

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

[Daniel P. Berrangé]

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.

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

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

[Peter Xu]

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

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

[Akihiko Odaki]

On 2025/12/10 1: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.
> 
> 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.

I'm actually less sure if the first half makes sense than the second half.

Exporting Property from QDEV did make me think it may be polluting the 
codebase with QDEV-specifics, but its motivation (creating properties 
without defining accessors) is clear and it meets its requirement.

The motivation is less concrete for the first half. It says the current 
code is explicit, but it is a relative term. I'm not sure if specifying 
TYPE_OBJECT_COMPAT is less explicit (or more implicit) than calling 
object_apply_compat_props(). Also, having a class for compat props but 
not for global props makes the decision look arbitrary. It is nice to 
have some clarification on these.

Regards,
Akihiko Odaki

> 
> 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(-)
> 

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

[Peter Xu]

On Fri, Dec 12, 2025 at 12:28:21AM +0900, Akihiko Odaki wrote:
> I'm actually less sure if the first half makes sense than the second half.
> 
> Exporting Property from QDEV did make me think it may be polluting the
> codebase with QDEV-specifics, but its motivation (creating properties
> without defining accessors) is clear and it meets its requirement.
> 
> The motivation is less concrete for the first half. It says the current code
> is explicit, but it is a relative term. I'm not sure if specifying
> TYPE_OBJECT_COMPAT is less explicit (or more implicit) than calling
> object_apply_compat_props(). Also, having a class for compat props but not
> for global props makes the decision look arbitrary. It is nice to have some
> clarification on these.

Thanks for the comments, Akihiko.  I can explain.

I explicitly only included object_apply_compat_props() in the current
OBJECT_COMPAT class (rather than set_globals()) is almost two-fold:

  - Inclusion of qdev_prop_set_globals() makes the 1st half start to depend
    on the 2nd half, that I don't see it strictly necessary.  E.g., one
    immediate motivation of me looking at this problem is Vladimir's series
    on virtio-net/tap [1].

    That series should only need patch 1-6 of this series as minimum to
    enable machine compat properties for TAP (after QOMify, if that makes
    sense on its own).

  - qdev_prop_set_globals() itself has a trivial dependency currently
    against qdev hotpluggable or not:

    object_apply_global_props(OBJECT(dev), global_props(),
                              dev->hotplugged ? NULL : &error_fatal);

    There's way to decouple that I guess, however I just don't see it
    necessary yet.  The only real user will be migration object, which
    doesn't need to depend on this anyway, as long as Property APIs can be
    exported.

Do you think we should keep open-code object_apply_compat_props() instead?

In reality, that also works for me at least on figuring out the current
problem [1], and if Property API exported I can also open code it for
migration object.  It's just that IMHO it's cleaner we have the light class
to do this (so as to avoid providng post_init() hooks all over the places).

[1] https://lore.kernel.org/all/20251030203116.870742-1-vsementsov@yandex-team.ru/

-- 
Peter Xu

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

[Akihiko Odaki]

On 2025/12/12 0:57, Peter Xu wrote:
> On Fri, Dec 12, 2025 at 12:28:21AM +0900, Akihiko Odaki wrote:
>> I'm actually less sure if the first half makes sense than the second half.
>>
>> Exporting Property from QDEV did make me think it may be polluting the
>> codebase with QDEV-specifics, but its motivation (creating properties
>> without defining accessors) is clear and it meets its requirement.
>>
>> The motivation is less concrete for the first half. It says the current code
>> is explicit, but it is a relative term. I'm not sure if specifying
>> TYPE_OBJECT_COMPAT is less explicit (or more implicit) than calling
>> object_apply_compat_props(). Also, having a class for compat props but not
>> for global props makes the decision look arbitrary. It is nice to have some
>> clarification on these.
> 
> Thanks for the comments, Akihiko.  I can explain.
> 
> I explicitly only included object_apply_compat_props() in the current
> OBJECT_COMPAT class (rather than set_globals()) is almost two-fold:
> 
>    - Inclusion of qdev_prop_set_globals() makes the 1st half start to depend
>      on the 2nd half, that I don't see it strictly necessary.  E.g., one
>      immediate motivation of me looking at this problem is Vladimir's series
>      on virtio-net/tap [1].
> 
>      That series should only need patch 1-6 of this series as minimum to
>      enable machine compat properties for TAP (after QOMify, if that makes
>      sense on its own).

It is possible to have another type that inherits TYPE_OBJECT_COMPAT and 
does the second half.

> 
>    - qdev_prop_set_globals() itself has a trivial dependency currently
>      against qdev hotpluggable or not:
> 
>      object_apply_global_props(OBJECT(dev), global_props(),
>                                dev->hotplugged ? NULL : &error_fatal);
> 
>      There's way to decouple that I guess, however I just don't see it
>      necessary yet.  The only real user will be migration object, which
>      doesn't need to depend on this anyway, as long as Property APIs can be
>      exported.

Theoretically, there may also be a call of object_apply_compat_props() 
that has some dependency on its state in the future, but such a future 
concern should be treated later; I'll focus on existing callers of 
object_apply_compat_props() and global_props() in the following 
discussion too.

> 
> Do you think we should keep open-code object_apply_compat_props() instead?

Yes, that's my conclusion so far, but please see below for the explanation:

> 
> In reality, that also works for me at least on figuring out the current
> problem [1], and if Property API exported I can also open code it for
> migration object.  It's just that IMHO it's cleaner we have the light class
> to do this (so as to avoid providng post_init() hooks all over the places).

Avoiding providing post_init() hooks is a nice concrete explanation of 
the goal.

That said, the migration object provides post_init() hooks anyway, so 
the question will be if avoiding post_init() hooks will simplify the 
existing callers of object_apply_compat_props().

Looking into the codebase, there are four users of 
object_apply_compat_props(); hostmem, qdev, accel, and sev. Only hostmem 
and qdev call object_apply_compat_props() in their post_init() hooks, 
and qdev needs the hook anyway for the same reason the migration object 
does.

So there is only one post_init() hook added for 
object_apply_compat_props(): host_memory_backend_post_init(). And even 
this can be simplified; since object_apply_compat_props() and the hook 
has the same signature, hostmem can simply do:

.instance_post_init = object_apply_compat_props,

... and drop host_memory_backend_post_init().

This is much simpler than adding the object-compat type, so probably 
it's too early to add the type.

Regards,
Akihiko Odaki

> 
> [1] https://lore.kernel.org/all/20251030203116.870742-1-vsementsov@yandex-team.ru/
> 

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

[Peter Xu]

On Fri, Dec 12, 2025 at 02:38:09PM +0900, Akihiko Odaki wrote:
> On 2025/12/12 0:57, Peter Xu wrote:
> > On Fri, Dec 12, 2025 at 12:28:21AM +0900, Akihiko Odaki wrote:
> > > I'm actually less sure if the first half makes sense than the second half.
> > > 
> > > Exporting Property from QDEV did make me think it may be polluting the
> > > codebase with QDEV-specifics, but its motivation (creating properties
> > > without defining accessors) is clear and it meets its requirement.
> > > 
> > > The motivation is less concrete for the first half. It says the current code
> > > is explicit, but it is a relative term. I'm not sure if specifying
> > > TYPE_OBJECT_COMPAT is less explicit (or more implicit) than calling
> > > object_apply_compat_props(). Also, having a class for compat props but not
> > > for global props makes the decision look arbitrary. It is nice to have some
> > > clarification on these.
> > 
> > Thanks for the comments, Akihiko.  I can explain.
> > 
> > I explicitly only included object_apply_compat_props() in the current
> > OBJECT_COMPAT class (rather than set_globals()) is almost two-fold:
> > 
> >    - Inclusion of qdev_prop_set_globals() makes the 1st half start to depend
> >      on the 2nd half, that I don't see it strictly necessary.  E.g., one
> >      immediate motivation of me looking at this problem is Vladimir's series
> >      on virtio-net/tap [1].
> > 
> >      That series should only need patch 1-6 of this series as minimum to
> >      enable machine compat properties for TAP (after QOMify, if that makes
> >      sense on its own).
> 
> It is possible to have another type that inherits TYPE_OBJECT_COMPAT and
> does the second half.

There's really not much user.  Especially if you're suggesting to not
introduce OBJECT_COMPAT, then I'd not consider that for now.

> 
> > 
> >    - qdev_prop_set_globals() itself has a trivial dependency currently
> >      against qdev hotpluggable or not:
> > 
> >      object_apply_global_props(OBJECT(dev), global_props(),
> >                                dev->hotplugged ? NULL : &error_fatal);
> > 
> >      There's way to decouple that I guess, however I just don't see it
> >      necessary yet.  The only real user will be migration object, which
> >      doesn't need to depend on this anyway, as long as Property APIs can be
> >      exported.
> 
> Theoretically, there may also be a call of object_apply_compat_props() that
> has some dependency on its state in the future, but such a future concern
> should be treated later; I'll focus on existing callers of
> object_apply_compat_props() and global_props() in the following discussion
> too.
> 
> > 
> > Do you think we should keep open-code object_apply_compat_props() instead?
> 
> Yes, that's my conclusion so far, but please see below for the explanation:
> 
> > 
> > In reality, that also works for me at least on figuring out the current
> > problem [1], and if Property API exported I can also open code it for
> > migration object.  It's just that IMHO it's cleaner we have the light class
> > to do this (so as to avoid providng post_init() hooks all over the places).
> 
> Avoiding providing post_init() hooks is a nice concrete explanation of the
> goal.
> 
> That said, the migration object provides post_init() hooks anyway, so the
> question will be if avoiding post_init() hooks will simplify the existing
> callers of object_apply_compat_props().
> 
> Looking into the codebase, there are four users of
> object_apply_compat_props(); hostmem, qdev, accel, and sev. Only hostmem and
> qdev call object_apply_compat_props() in their post_init() hooks, and qdev
> needs the hook anyway for the same reason the migration object does.
> 
> So there is only one post_init() hook added for object_apply_compat_props():
> host_memory_backend_post_init(). And even this can be simplified; since
> object_apply_compat_props() and the hook has the same signature, hostmem can
> simply do:
> 
> .instance_post_init = object_apply_compat_props,
> 
> ... and drop host_memory_backend_post_init().
> 
> This is much simpler than adding the object-compat type, so probably it's
> too early to add the type.

Yes, this looks also good enough for now.

When looking at this problem, my real goal was not OBJECT_COMPAT, but
allowing TYPE_OBJECT to opt-in with machine compat properties, then I found
these users.  I was expecting a new class would help, and maybe that should
at some point become the standard for backends.  Then device backends can
do the same as frontend on inheriting machine properties.

As long as we can reach a consensus providing that feature to TYPE_OBJECT
one way or another, it'll be good enough.

I'll wait a while to see whether others have further inputs.

Thanks,

-- 
Peter Xu

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

[Cédric Le Goater]

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(-)
> 

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

[Peter Xu]

On Thu, Dec 11, 2025 at 05:29:37PM +0100, Cédric Le Goater wrote:
> 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 ?

Maybe not exactly.

I only roughly read through SPAPR_CAP_HTM as an example, please help double
check if I misread it - I think such falls more into what Dan mentioned on
query-platform.

I am guessing CPU class of other archs should use similar concept, but I'm
not familiar with how it was done right now with QEMU/Libvirt.

So we have two standard categories of problems:

  (1) A new feature, the feature should almost always be enabled on new
      QEMUs, but need to be kept disabled when it can be migrated from old
      QEMUs.  It has nothing to do with the host / platform.

  (2) A new feature, the feature should normally be enabled only whenever
      the host HW/kernel supports it.

This series should try to solve problem (1) on non-qdev objects; it was
working properly for TYPE_DEVICE even before this series.  It doesn't yet
solve problem (2).  Problem (2), as a generic approach, may need something
like query-platform as Dan used to suggest.

IIUC all the spapr caps will still be needed, and I believe Libvirt knows
how to query caps in this case for spapr. It's a matter of if we should
have an unified interface to probe all of host capabilities, which should
not only include things like kvmppc_has_cap_htm(), but all the rest
platform info like TAP USO supports, in one batch to Libvirt. So Libvirt
takes it as "host information", plus user decisions to further decide the
QEMU cmdlines (or QMP commands used to create the system emulation).
That'll also include the -M cap-htm=XX properties to be used.

Considering that we should have ways Libvirt probing these.. maybe we do
not need to merge everything into a new QMP query-platform, but we can
consider putting all the new host info into that one command from now on.

Thanks,

-- 
Peter Xu