Re: [PATCH v2 10/10] migration: Switch to TYPE_OBJECT with object properties

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

On Tue, Jun 09, 2026 at 01:25:14PM -0400, Peter Xu wrote:
> The migration object used to depend on TYPE_DEVICE due to:
> 
> - Usage of qdev properties
> - Apply compat properties and global properties
> 
> This patch re-based the object to TYPE_OBJECT with the changes:
> 
> - Switch to object properties API
> - Manually apply both compat and global properties in post_init()
> 
> Note that to avoid too many property getter/setter helpers, this patch used
> the object_property_add_*_ptr_def() APIs so that an pointer is passed to
> bind to the property.  Such API is used for most of the conversions.
> 
> After patch, the migration object initializes instance properties within
> its instance_init() callback, in migrate_params_init().
> 
> One side effect of this change is, since we switched to a loop to add all
> capabilities, the name of the properties representing a migration
> capability may chance from previously hard-coded ones (many with x-).  It's
> fine since it's only used in -global so it's only for debugging.
> 
> Similarly, I removed "x-" from other properites that used to start with
> "x-" but actually are not experimental.
> 
> After the whole conversion, we don't need migration_properties or the count
> anymore, hence can be removed.  While at it, we can also remove two
> DEFINE_PROP*() API that only migration uses (DEFINE_PROP_STR_OR_NULL, and
> DEFINE_PROP_MIG_CAP).
> 
> Signed-off-by: Peter Xu <peterx@redhat.com>
> ---
>  migration/options.h   |   8 +-
>  migration/migration.c |  35 ++-
>  migration/options.c   | 526 ++++++++++++++++++++++++++----------------
>  3 files changed, 351 insertions(+), 218 deletions(-)

> +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.
> +     * Apply these properties on top of default values:
> +     *
> +     * (1) machine compat properties
> +     * (2) -global settings in cmdlines
>       *
> -     * TODO: Make this TYPE_OBJECT once QOM provides something like
> -     * TYPE_DEVICE's "-global" properties.
> +     * Need to be applied in order so (2) takes precedence over (1).
>       */
> -    .parent = TYPE_DEVICE,
> -    .class_init = migration_class_init,
> +    object_apply_compat_props(obj);
> +    object_apply_global_props(obj, global_props(), &error_fatal);

-global is/was intended for devices, primarily those which
are created by default as part of the machine. For dynamically
created devices the docs recommend use of -device instead
of -global.

I get that -global was exposed for migration via the inappropriate
use of TYPE_DEVICE as a parent for TYPE_MIGRATION, but I don't
think we should be prolonging that misuse by exposing use of
-global for things which are QOM rather than QDev.

If we want todo that for the sake of backcompat, IMHO it should
be deprecated so it only lives for a short while after the
conversion to QOM.

This makes me realize that this does not implement the UserCreatable
interface on TYPE_MIGRATION, so I'm presuming the MigrationState is
still created internally. Perhaps we should switch to making it a
full UserCreatable, such that -object can be used to set all migration
parameters on the command line and -global won't be required ? 

> +}
> +
> +static const TypeInfo migration_type = {
> +    .name = TYPE_MIGRATION,
> +    .parent = TYPE_OBJECT,
>      .instance_size = sizeof(MigrationState),
>      .instance_init = migration_instance_init,
> +    .instance_post_init = migration_instance_post_init,
>      .instance_finalize = migration_instance_finalize,
>  };

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|