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();
>>
next prev parent 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).