qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: Peter Xu <peterx@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, berrange@redhat.com
Subject: Re: [PATCH v2 02/24] migration: Add a qdev property for StrOrNull
Date: Fri, 04 Jul 2025 09:58:22 -0300	[thread overview]
Message-ID: <87ms9k3yfl.fsf@suse.de> (raw)
In-Reply-To: <aGcE6Av_IBOGBNvD@x1.local>

Peter Xu <peterx@redhat.com> writes:

> On Tue, Jul 01, 2025 at 08:38:19AM +0200, Markus Armbruster wrote:
>> Fabiano Rosas <farosas@suse.de> writes:
>> 
>> > The MigrationState is a QOM object with TYPE_DEVICE as a parent. This
>> > was done about eight years ago so the migration code could make use of
>> > qdev properties to define the defaults for the migration parameters
>> > and to be able to expose migration knobs for debugging via the
>> > '-global migration' command line option.
>> >
>> > Due to unrelated historical reasons, three of the migration parameters
>> > (TLS options) received different types when used via the
>> > query-migrate-parameters QMP command than with the
>> > migrate-set-parameters command. This has created a lot of duplication
>> > in the migration code and in the QAPI documentation because the whole
>> > of MigrationParameters had to be duplicated as well.
>> >
>> > The migration code is now being fixed to remove the duplication and
>> > for that to happen the offending fields need to be reconciled into a
>> > single type. The StrOrNull type is going to be used.
>> >
>> > To keep the command line compatibility, the parameters need to
>> > continue being exposed via qdev properties accessible from the command
>> > line. Introduce a qdev property StrOrNull just for that.
>> >
>> > Note that this code is being kept in migration/options.c because this
>> > version of StrOrNull doesn't need to handle QNULL because it was never
>> > a valid option in the previous command line, which took a string.
>> >
>> > Signed-off-by: Fabiano Rosas <farosas@suse.de>
>> > ---
>> >  migration/options.c | 47 +++++++++++++++++++++++++++++++++++++++++++++
>> >  1 file changed, 47 insertions(+)
>> >
>> > diff --git a/migration/options.c b/migration/options.c
>> > index 162c72cda4..384ef9e421 100644
>> > --- a/migration/options.c
>> > +++ b/migration/options.c
>> > @@ -83,6 +83,11 @@
>> >  #define DEFINE_PROP_MIG_CAP(name, x)             \
>> >      DEFINE_PROP_BOOL(name, MigrationState, capabilities[x], false)
>> >  
>> > +const PropertyInfo qdev_prop_StrOrNull;
>> > +#define DEFINE_PROP_STR_OR_NULL(_name, _state, _field)                  \
>> > +    DEFINE_PROP(_name, _state, _field, qdev_prop_StrOrNull, StrOrNull *, \
>> > +                .set_default = true)
>> > +
>> >  #define DEFAULT_MIGRATE_VCPU_DIRTY_LIMIT_PERIOD     1000    /* milliseconds */
>> >  #define DEFAULT_MIGRATE_VCPU_DIRTY_LIMIT            1       /* MB/s */
>> >  
>> > @@ -204,6 +209,48 @@ const Property migration_properties[] = {
>> >  };
>> >  const size_t migration_properties_count = ARRAY_SIZE(migration_properties);
>> >  
>> > +/*
>> > + * qdev property for TLS options handling via '-global migration'
>> > + * command line.
>> > + */
>> 
>> Looks like this was a function comment.  It's not, it applies to the
>> PropertyInfo and its method.  Move it to the PropertyInfo?
>> 
>> Maybe
>> 
>>    /*
>>     * String property like qdev_prop_string, except it's backed by a
>>     * StrOrNull * instead of a char *.  This is intended for
>>     * TYPE_MIGRATION's TLS options.
>>     */
>> 
>> > +static void set_StrOrNull(Object *obj, Visitor *v, const char *name,
>> > +                          void *opaque, Error **errp)
>> > +{
>> > +    const Property *prop = opaque;
>> > +    StrOrNull **ptr = object_field_prop_ptr(obj, prop);
>> > +    StrOrNull *str_or_null = g_new0(StrOrNull, 1);
>> > +
>> > +    /*
>> > +     * Only str to keep compatibility, QNULL was never used via
>> > +     * command line.
>> > +     */
>> > +    str_or_null->type = QTYPE_QSTRING;
>> > +    if (!visit_type_str(v, name, &str_or_null->u.s, errp)) {
>> > +        return;
>> > +    }
>> > +
>> > +    qapi_free_StrOrNull(*ptr);
>> > +    *ptr = str_or_null;
>> > +}
>> > +
>> > +static void release_StrOrNull(Object *obj, const char *name, void *opaque)
>> > +{
>> > +    const Property *prop = opaque;
>> > +    qapi_free_StrOrNull(*(StrOrNull **)object_field_prop_ptr(obj, prop));
>> > +}
>> > +
>> > +static void set_default_value_tls_opt(ObjectProperty *op, const Property *prop)
>> > +{
>> > +    object_property_set_default_str(op, "");
>> > +}
>> > +
>> > +const PropertyInfo qdev_prop_StrOrNull = {
>> > +    .type  = "StrOrNull",
>> > +    .set = set_StrOrNull,
>> > +    .release = release_StrOrNull,
>> > +    .set_default_value = set_default_value_tls_opt,
>> > +};
>> 
>> No getter, i.e. properties will be write-only.  This is unusual.  Is it
>> safe?
>
> Fair question..
>
> I had a quick look, device_class_set_props_n() will try to register the
> prop with legacy mode first then modern mode.  Legacy mode is decided by
> [1] below:
>
> static void qdev_class_add_legacy_property(DeviceClass *dc, const Property *prop)
> {
>     g_autofree char *name = NULL;
>
>     /* Register pointer properties as legacy properties */
>     if (!prop->info->print && prop->info->get) { <------------------ [1]
>         return;
>     }
>
>     name = g_strdup_printf("legacy-%s", prop->name);
>     object_class_property_add(OBJECT_CLASS(dc), name, "str",
>         prop->info->print ? qdev_get_legacy_property : prop->info->get,
>         NULL, NULL, (Property *)prop);
> }
>
> When with no get(), it seems it'll be wrongly treated as legacy property..
> which further means whoever tries to get() on the property will invoke
> qdev_get_legacy_property(), and likely crash on accessing info->print()..
>
> The other issue is legacy property doesn't look like to provide a setter
> function.. as it's passing NULL to object_class_property_add(set=XXX).
>
> Likely we'll need to provide get() if without changing qdev code.
>

Peter, thank you for the analysis and sorry all for not commenting on
this earlier. I have reached the same conclusions and have implemented
the .get method.

>> 
>> > +
>> >  bool migrate_auto_converge(void)
>> >  {
>> >      MigrationState *s = migrate_get_current();
>> 


  reply	other threads:[~2025-07-04 12:59 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-30 19:58 [PATCH v2 00/24] migration: Unify capabilities and parameters Fabiano Rosas
2025-06-30 19:58 ` [PATCH v2 01/24] migration: Fix leak of block_bitmap_mapping Fabiano Rosas
2025-07-01  6:12   ` Markus Armbruster
2025-07-03 21:31     ` Peter Xu
2025-07-04  5:09       ` Markus Armbruster
2025-06-30 19:58 ` [PATCH v2 02/24] migration: Add a qdev property for StrOrNull Fabiano Rosas
2025-07-01  6:38   ` Markus Armbruster
2025-07-03 22:32     ` Peter Xu
2025-07-04 12:58       ` Fabiano Rosas [this message]
2025-06-30 19:58 ` [PATCH v2 03/24] migration: Normalize tls arguments Fabiano Rosas
2025-07-01  7:46   ` Markus Armbruster
2025-07-01 14:20     ` Fabiano Rosas
2025-07-04 13:12       ` Fabiano Rosas
2025-07-04 15:37         ` Peter Xu
2025-08-20 15:45           ` Fabiano Rosas
2025-06-30 19:58 ` [PATCH v2 04/24] migration: Remove MigrateSetParameters Fabiano Rosas
2025-07-01  8:00   ` Markus Armbruster
2025-07-03 19:34     ` Fabiano Rosas
2025-07-04  4:25       ` Markus Armbruster
2025-07-04 15:39   ` Peter Xu
2025-06-30 19:58 ` [PATCH v2 05/24] qapi/migration: Don't document MigrationParameter Fabiano Rosas
2025-07-01  8:04   ` Markus Armbruster
2025-07-04 15:40   ` Peter Xu
2025-06-30 19:58 ` [PATCH v2 06/24] migration: Run a post update routine after setting parameters Fabiano Rosas
2025-06-30 19:58 ` [PATCH v2 07/24] migration: Add a flag to track block-bitmap-mapping input Fabiano Rosas
2025-07-04 15:42   ` Peter Xu
2025-06-30 19:58 ` [PATCH v2 08/24] migration: Remove checks for s->parameters has_* fields Fabiano Rosas
2025-06-30 19:58 ` [PATCH v2 09/24] migration: Do away with usage of QERR_INVALID_PARAMETER_VALUE Fabiano Rosas
2025-07-04 16:04   ` Peter Xu
2025-06-30 19:58 ` [PATCH v2 10/24] migration: Extract code to mark all parameters as present Fabiano Rosas
2025-06-30 19:59 ` [PATCH v2 11/24] migration: Use QAPI_CLONE_MEMBERS in query_migrate_parameters Fabiano Rosas
2025-07-04 16:11   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 12/24] migration: Use QAPI_CLONE_MEMBERS in migrate_params_test_apply Fabiano Rosas
2025-06-30 19:59 ` [PATCH v2 13/24] migration: Use QAPI_CLONE_MEMBERS in migrate_params_apply Fabiano Rosas
2025-08-13 19:05   ` Peter Xu
2025-08-14 15:04     ` Fabiano Rosas
2025-06-30 19:59 ` [PATCH v2 14/24] migration: Use visitors in migrate_params_test_apply Fabiano Rosas
2025-08-13 20:05   ` Peter Xu
2025-08-14 15:10     ` Fabiano Rosas
2025-08-14 19:40       ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 15/24] migration: Cleanup hmp_info_migrate_parameters Fabiano Rosas
2025-08-13 20:40   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 16/24] migration: Add capabilities into MigrationParameters Fabiano Rosas
2025-07-01  8:25   ` Markus Armbruster
2025-07-04 13:15     ` Fabiano Rosas
2025-07-04 14:04       ` Markus Armbruster
2025-07-04 14:48         ` Fabiano Rosas
2025-07-04 15:04           ` Markus Armbruster
2025-07-04 16:33   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 17/24] migration: Remove s->capabilities Fabiano Rosas
2025-08-13 20:48   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 18/24] qapi/migration: Deprecate capabilities commands Fabiano Rosas
2025-07-01  8:30   ` Markus Armbruster
2025-07-01  8:38   ` Jiri Denemark
2025-07-01  9:00     ` Peter Krempa
2025-07-01  9:10     ` Daniel P. Berrangé
2025-08-13 20:50   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 19/24] migration: Store the initial values used for s->parameters Fabiano Rosas
2025-08-13 21:09   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 20/24] migration: Allow migrate commands to provide the migration config Fabiano Rosas
2025-07-01  8:35   ` Markus Armbruster
2025-08-13 21:27   ` Peter Xu
2025-08-14 15:13     ` Fabiano Rosas
2025-06-30 19:59 ` [PATCH v2 21/24] tests/qtest/migration: Take reference when passing %p to qtest_qmp Fabiano Rosas
2025-08-13 22:22   ` Peter Xu
2025-08-21 17:20     ` Fabiano Rosas
2025-06-30 19:59 ` [PATCH v2 22/24] tests/qtest/migration: Adapt the capabilities helper to take a config Fabiano Rosas
2025-08-14 14:02   ` Peter Xu
2025-06-30 19:59 ` [PATCH v2 23/24] tests/qtest/migration: Adapt convergence routines to config Fabiano Rosas
2025-06-30 19:59 ` [PATCH v2 24/24] tests/qtest/migration: Pass the migration config to file tests Fabiano Rosas
2025-08-14 14:24   ` Peter Xu
2025-08-14 15:30     ` Fabiano Rosas
2025-08-14 19:45       ` Peter Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ms9k3yfl.fsf@suse.de \
    --to=farosas@suse.de \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).