[for-8.2,v2,1/2] qapi/migration: Deduplicate migration parameter field comments

We used to have three objects that have always the same list of parameters
and comments are always duplicated:

  - @MigrationParameter
  - @MigrationParameters
  - @MigrateSetParameters

Before we can deduplicate the code, it's fairly straightforward to
deduplicate the comments first, so for each time we add a new migration
parameter we don't need to copy the same paragraphs three times.

Make the @MigrationParameter the major source of truth, while leaving the
rest two to reference to it.

We do have a slight problem in the man/html pages generated, that for the
latter two objects we'll get a list of Members but with all of them saying
"Not documented":

   Members
       announce-initial: int (optional)
              Not documented

       announce-max: int (optional)
              Not documented

       announce-rounds: int (optional)
              Not documented

       [...]

Even though we'll have a reference there telling the reader to jump over to
read the @MigrationParameter sections instead, for example:

   MigrationParameters (Object)

       The object structure to represent a list of migration parameters.
       The optional members aren't actually optional.  For detailed
       explanation for each of the field, please refer to the documentation
       of MigrationParameter.

So hopefully that's not too bad.. and we can leave it for later to make it
even better.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 qapi/migration.json | 283 ++------------------------------------------
 1 file changed, 7 insertions(+), 276 deletions(-)

Peter Xu <peterx@redhat.com> writes:

> We used to have three objects that have always the same list of parameters

We have!

> and comments are always duplicated:
>
>   - @MigrationParameter
>   - @MigrationParameters
>   - @MigrateSetParameters
>
> Before we can deduplicate the code, it's fairly straightforward to
> deduplicate the comments first, so for each time we add a new migration
> parameter we don't need to copy the same paragraphs three times.

De-duplicating the code would be nice, but we haven't done so in years,
which suggests it's hard enough not to be worth the trouble.

De-duplicating the documentation is certainly easier.

Is that what you're trying to say?

Our discussion pros and cons that is happening in review of v1 should be
captured in the commit message, right here.

> Make the @MigrationParameter the major source of truth, while leaving the
> rest two to reference to it.

Any particular reason for picking this one?

> We do have a slight problem in the man/html pages generated, that for the
> latter two objects we'll get a list of Members but with all of them saying
> "Not documented":
>
>    Members
>        announce-initial: int (optional)
>               Not documented
>
>        announce-max: int (optional)
>               Not documented
>
>        announce-rounds: int (optional)
>               Not documented
>
>        [...]
>
> Even though we'll have a reference there telling the reader to jump over to
> read the @MigrationParameter sections instead, for example:
>
>    MigrationParameters (Object)
>
>        The object structure to represent a list of migration parameters.
>        The optional members aren't actually optional.  For detailed
>        explanation for each of the field, please refer to the documentation
>        of MigrationParameter.
>
> So hopefully that's not too bad.. and we can leave it for later to make it
> even better.

It's plenty bad, I'm afraid.  It comes out as a short paragraph "don't
look here, look there", followed by screenfuls claiming "not
documented."  Embarrassing.  Worse, *misleading*, because the short
paragraph is easy to miss.

Also discussed in review of v1.  Let's continue there, to avoid
splitting the thread.

> Signed-off-by: Peter Xu <peterx@redhat.com>

On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> Peter Xu <peterx@redhat.com> writes:
> 
> > We used to have three objects that have always the same list of parameters
> 
> We have!
> 
> > and comments are always duplicated:
> >
> >   - @MigrationParameter
> >   - @MigrationParameters
> >   - @MigrateSetParameters
> >
> > Before we can deduplicate the code, it's fairly straightforward to
> > deduplicate the comments first, so for each time we add a new migration
> > parameter we don't need to copy the same paragraphs three times.
> 
> De-duplicating the code would be nice, but we haven't done so in years,
> which suggests it's hard enough not to be worth the trouble.

The "MigrationParameter" enumeration isn't actually used in
QMP at all.

It is only used in HMP for hmp_migrate_set_parameter and
hmp_info_migrate_parameters. So it is questionable documenting
that enum in the QMP reference docs at all.

1c1
< { 'struct': 'MigrationParameters',
---
> { 'struct': 'MigrateSetParameters',
14,16c14,16
<             '*tls-creds': 'str',
<             '*tls-hostname': 'str',
<             '*tls-authz': 'str',
---
>             '*tls-creds': 'StrOrNull',
>             '*tls-hostname': 'StrOrNull',
>             '*tls-authz': 'StrOrNull',

Is it not valid to use StrOrNull in both cases and thus
delete the duplication here ?

With regards,
Daniel

On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> > Peter Xu <peterx@redhat.com> writes:
> > 
> > > We used to have three objects that have always the same list of parameters
> > 
> > We have!
> > 
> > > and comments are always duplicated:
> > >
> > >   - @MigrationParameter
> > >   - @MigrationParameters
> > >   - @MigrateSetParameters
> > >
> > > Before we can deduplicate the code, it's fairly straightforward to
> > > deduplicate the comments first, so for each time we add a new migration
> > > parameter we don't need to copy the same paragraphs three times.
> > 
> > De-duplicating the code would be nice, but we haven't done so in years,
> > which suggests it's hard enough not to be worth the trouble.
> 
> The "MigrationParameter" enumeration isn't actually used in
> QMP at all.
> 
> It is only used in HMP for hmp_migrate_set_parameter and
> hmp_info_migrate_parameters. So it is questionable documenting
> that enum in the QMP reference docs at all.
> 
> 1c1
> < { 'struct': 'MigrationParameters',
> ---
> > { 'struct': 'MigrateSetParameters',
> 14,16c14,16
> <             '*tls-creds': 'str',
> <             '*tls-hostname': 'str',
> <             '*tls-authz': 'str',
> ---
> >             '*tls-creds': 'StrOrNull',
> >             '*tls-hostname': 'StrOrNull',
> >             '*tls-authz': 'StrOrNull',
> 
> Is it not valid to use StrOrNull in both cases and thus
> delete the duplication here ?

I tested removing MigrateSetParameters by replacing it with
MigrationParameters and it looks all fine here... I manually tested qmp/hmp
on set/query parameters, and qtests are all happy.

The only thing I see that may affect it is we used to logically allow
taking things like '"tls-authz": null' in the json input, but now we won't
allow that because we'll be asking for a string type only.

Since we have query-qmp-schema I suppose we're all fine, because logically
the mgmt app (libvirt?) will still query that to understand the protocol,
so now we'll have (response of query-qmp-schema):

        {
            "arg-type": "144",
            "meta-type": "command",
            "name": "migrate-set-parameters",
            "ret-type": "0"
        },

Where 144 can start to point to MigrationParameters, rather than
MigrateSetParameters.

Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
fields when setting?  Funnily I tried it and actually anything that does
migrate-set-parameters with a "null" passed over to tls-* fields will
already crash qemu...

./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.

#0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
#1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
#2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
#3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
#4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
#5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
#6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
#7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
#8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
#9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
#10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
#11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
#12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
#13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
#15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
#16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
#17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
#18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
#19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48

Then I suppose it means all mgmt apps are not using "null" anyway, and it
makes more sense to me to just remove MigrateSetParameters (by replacing it
with MigrationParameters).

Then if we can also replace MigrationParameter enum with an internal enum
(alongside with a _str[] array for it) it seems we're all fine to dedup the
3 objects into 1 in qapi schema.

Thanks,

On Fri, Aug 04, 2023 at 12:01:54PM -0400, Peter Xu wrote:
> On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> > > Peter Xu <peterx@redhat.com> writes:
> > > 
> > > > We used to have three objects that have always the same list of parameters
> > > 
> > > We have!
> > > 
> > > > and comments are always duplicated:
> > > >
> > > >   - @MigrationParameter
> > > >   - @MigrationParameters
> > > >   - @MigrateSetParameters
> > > >
> > > > Before we can deduplicate the code, it's fairly straightforward to
> > > > deduplicate the comments first, so for each time we add a new migration
> > > > parameter we don't need to copy the same paragraphs three times.
> > > 
> > > De-duplicating the code would be nice, but we haven't done so in years,
> > > which suggests it's hard enough not to be worth the trouble.
> > 
> > The "MigrationParameter" enumeration isn't actually used in
> > QMP at all.
> > 
> > It is only used in HMP for hmp_migrate_set_parameter and
> > hmp_info_migrate_parameters. So it is questionable documenting
> > that enum in the QMP reference docs at all.
> > 
> > 1c1
> > < { 'struct': 'MigrationParameters',
> > ---
> > > { 'struct': 'MigrateSetParameters',
> > 14,16c14,16
> > <             '*tls-creds': 'str',
> > <             '*tls-hostname': 'str',
> > <             '*tls-authz': 'str',
> > ---
> > >             '*tls-creds': 'StrOrNull',
> > >             '*tls-hostname': 'StrOrNull',
> > >             '*tls-authz': 'StrOrNull',
> > 
> > Is it not valid to use StrOrNull in both cases and thus
> > delete the duplication here ?
> 
> I tested removing MigrateSetParameters by replacing it with
> MigrationParameters and it looks all fine here... I manually tested qmp/hmp
> on set/query parameters, and qtests are all happy.

I meant the other way around, such we would be using 'StrOrNull'
in all scenarios.

> 
> The only thing I see that may affect it is we used to logically allow
> taking things like '"tls-authz": null' in the json input, but now we won't
> allow that because we'll be asking for a string type only.
> 
> Since we have query-qmp-schema I suppose we're all fine, because logically
> the mgmt app (libvirt?) will still query that to understand the protocol,
> so now we'll have (response of query-qmp-schema):
> 
>         {
>             "arg-type": "144",
>             "meta-type": "command",
>             "name": "migrate-set-parameters",
>             "ret-type": "0"
>         },
> 
> Where 144 can start to point to MigrationParameters, rather than
> MigrateSetParameters.
> 
> Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
> fields when setting?  Funnily I tried it and actually anything that does
> migrate-set-parameters with a "null" passed over to tls-* fields will
> already crash qemu...
> 
> ./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.
> 
> #0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
> #1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
> #2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
> #3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
> #4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
> #5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
> #6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
> #7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
> #8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
> #9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
> #10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
> #11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
> #12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
> #13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> #14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
> #15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
> #16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
> #17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
> #18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
> #19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48
> 
> Then I suppose it means all mgmt apps are not using "null" anyway, and it
> makes more sense to me to just remove MigrateSetParameters (by replacing it
> with MigrationParameters).

It shouldn't be crashing,  because qmp_migrate_set_parameters()
is turning 'null' into  "", which means the assert ought to
never fire. Did you have a local modiification that caused
this crash perhaps ?

With regards,
Daniel

On Fri, Aug 04, 2023 at 05:29:19PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 04, 2023 at 12:01:54PM -0400, Peter Xu wrote:
> > On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> > > > Peter Xu <peterx@redhat.com> writes:
> > > > 
> > > > > We used to have three objects that have always the same list of parameters
> > > > 
> > > > We have!
> > > > 
> > > > > and comments are always duplicated:
> > > > >
> > > > >   - @MigrationParameter
> > > > >   - @MigrationParameters
> > > > >   - @MigrateSetParameters
> > > > >
> > > > > Before we can deduplicate the code, it's fairly straightforward to
> > > > > deduplicate the comments first, so for each time we add a new migration
> > > > > parameter we don't need to copy the same paragraphs three times.
> > > > 
> > > > De-duplicating the code would be nice, but we haven't done so in years,
> > > > which suggests it's hard enough not to be worth the trouble.
> > > 
> > > The "MigrationParameter" enumeration isn't actually used in
> > > QMP at all.
> > > 
> > > It is only used in HMP for hmp_migrate_set_parameter and
> > > hmp_info_migrate_parameters. So it is questionable documenting
> > > that enum in the QMP reference docs at all.
> > > 
> > > 1c1
> > > < { 'struct': 'MigrationParameters',
> > > ---
> > > > { 'struct': 'MigrateSetParameters',
> > > 14,16c14,16
> > > <             '*tls-creds': 'str',
> > > <             '*tls-hostname': 'str',
> > > <             '*tls-authz': 'str',
> > > ---
> > > >             '*tls-creds': 'StrOrNull',
> > > >             '*tls-hostname': 'StrOrNull',
> > > >             '*tls-authz': 'StrOrNull',
> > > 
> > > Is it not valid to use StrOrNull in both cases and thus
> > > delete the duplication here ?
> > 
> > I tested removing MigrateSetParameters by replacing it with
> > MigrationParameters and it looks all fine here... I manually tested qmp/hmp
> > on set/query parameters, and qtests are all happy.
> 
> I meant the other way around, such we would be using 'StrOrNull'
> in all scenarios.

Yes, that should also work and even without worrying on nulls.  I just took
a random one replacing the other.

> 
> > 
> > The only thing I see that may affect it is we used to logically allow
> > taking things like '"tls-authz": null' in the json input, but now we won't
> > allow that because we'll be asking for a string type only.
> > 
> > Since we have query-qmp-schema I suppose we're all fine, because logically
> > the mgmt app (libvirt?) will still query that to understand the protocol,
> > so now we'll have (response of query-qmp-schema):
> > 
> >         {
> >             "arg-type": "144",
> >             "meta-type": "command",
> >             "name": "migrate-set-parameters",
> >             "ret-type": "0"
> >         },
> > 
> > Where 144 can start to point to MigrationParameters, rather than
> > MigrateSetParameters.
> > 
> > Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
> > fields when setting?  Funnily I tried it and actually anything that does
> > migrate-set-parameters with a "null" passed over to tls-* fields will
> > already crash qemu...
> > 
> > ./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.
> > 
> > #0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
> > #1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
> > #2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
> > #3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
> > #4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
> > #5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
> > #6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
> > #7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
> > #8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
> > #9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
> > #10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
> > #11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
> > #12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
> > #13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> > #14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
> > #15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
> > #16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
> > #17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
> > #18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
> > #19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48
> > 
> > Then I suppose it means all mgmt apps are not using "null" anyway, and it
> > makes more sense to me to just remove MigrateSetParameters (by replacing it
> > with MigrationParameters).
> 
> It shouldn't be crashing,  because qmp_migrate_set_parameters()
> is turning 'null' into  "", which means the assert ought to
> never fire. Did you have a local modiification that caused
> this crash perhaps ?

I think it just got overlooked when introducing tls-authz to not have added
that special code in qmp_migrate_set_parameters(), the other two are fine.

Thanks,

On Fri, Aug 04, 2023 at 12:46:18PM -0400, Peter Xu wrote:
> On Fri, Aug 04, 2023 at 05:29:19PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Aug 04, 2023 at 12:01:54PM -0400, Peter Xu wrote:
> > > On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
> > > > On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> > > > > Peter Xu <peterx@redhat.com> writes:
> > > > > 
> > > > > > We used to have three objects that have always the same list of parameters
> > > > > 
> > > > > We have!
> > > > > 
> > > > > > and comments are always duplicated:
> > > > > >
> > > > > >   - @MigrationParameter
> > > > > >   - @MigrationParameters
> > > > > >   - @MigrateSetParameters
> > > > > >
> > > > > > Before we can deduplicate the code, it's fairly straightforward to
> > > > > > deduplicate the comments first, so for each time we add a new migration
> > > > > > parameter we don't need to copy the same paragraphs three times.
> > > > > 
> > > > > De-duplicating the code would be nice, but we haven't done so in years,
> > > > > which suggests it's hard enough not to be worth the trouble.
> > > > 
> > > > The "MigrationParameter" enumeration isn't actually used in
> > > > QMP at all.
> > > > 
> > > > It is only used in HMP for hmp_migrate_set_parameter and
> > > > hmp_info_migrate_parameters. So it is questionable documenting
> > > > that enum in the QMP reference docs at all.
> > > > 
> > > > 1c1
> > > > < { 'struct': 'MigrationParameters',
> > > > ---
> > > > > { 'struct': 'MigrateSetParameters',
> > > > 14,16c14,16
> > > > <             '*tls-creds': 'str',
> > > > <             '*tls-hostname': 'str',
> > > > <             '*tls-authz': 'str',
> > > > ---
> > > > >             '*tls-creds': 'StrOrNull',
> > > > >             '*tls-hostname': 'StrOrNull',
> > > > >             '*tls-authz': 'StrOrNull',
> > > > 
> > > > Is it not valid to use StrOrNull in both cases and thus
> > > > delete the duplication here ?
> > > 
> > > I tested removing MigrateSetParameters by replacing it with
> > > MigrationParameters and it looks all fine here... I manually tested qmp/hmp
> > > on set/query parameters, and qtests are all happy.
> > 
> > I meant the other way around, such we would be using 'StrOrNull'
> > in all scenarios.
> 
> Yes, that should also work and even without worrying on nulls.  I just took
> a random one replacing the other.
> 
> > 
> > > 
> > > The only thing I see that may affect it is we used to logically allow
> > > taking things like '"tls-authz": null' in the json input, but now we won't
> > > allow that because we'll be asking for a string type only.
> > > 
> > > Since we have query-qmp-schema I suppose we're all fine, because logically
> > > the mgmt app (libvirt?) will still query that to understand the protocol,
> > > so now we'll have (response of query-qmp-schema):
> > > 
> > >         {
> > >             "arg-type": "144",
> > >             "meta-type": "command",
> > >             "name": "migrate-set-parameters",
> > >             "ret-type": "0"
> > >         },
> > > 
> > > Where 144 can start to point to MigrationParameters, rather than
> > > MigrateSetParameters.
> > > 
> > > Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
> > > fields when setting?  Funnily I tried it and actually anything that does
> > > migrate-set-parameters with a "null" passed over to tls-* fields will
> > > already crash qemu...
> > > 
> > > ./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.
> > > 
> > > #0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
> > > #1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
> > > #2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
> > > #3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
> > > #4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
> > > #5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
> > > #6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
> > > #7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
> > > #8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
> > > #9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
> > > #10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
> > > #11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
> > > #12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
> > > #13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> > > #14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
> > > #15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
> > > #16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
> > > #17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
> > > #18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
> > > #19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48
> > > 
> > > Then I suppose it means all mgmt apps are not using "null" anyway, and it
> > > makes more sense to me to just remove MigrateSetParameters (by replacing it
> > > with MigrationParameters).
> > 
> > It shouldn't be crashing,  because qmp_migrate_set_parameters()
> > is turning 'null' into  "", which means the assert ought to
> > never fire. Did you have a local modiification that caused
> > this crash perhaps ?
> 
> I think it just got overlooked when introducing tls-authz to not have added
> that special code in qmp_migrate_set_parameters(), the other two are fine.

Oh right yes, pre-existing bug.

With regards,
Daniel

On Fri, Aug 04, 2023 at 05:48:49PM +0100, Daniel P. Berrangé wrote:
> On Fri, Aug 04, 2023 at 12:46:18PM -0400, Peter Xu wrote:
> > On Fri, Aug 04, 2023 at 05:29:19PM +0100, Daniel P. Berrangé wrote:
> > > On Fri, Aug 04, 2023 at 12:01:54PM -0400, Peter Xu wrote:
> > > > On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
> > > > > On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> > > > > > Peter Xu <peterx@redhat.com> writes:
> > > > > > 
> > > > > > > We used to have three objects that have always the same list of parameters
> > > > > > 
> > > > > > We have!
> > > > > > 
> > > > > > > and comments are always duplicated:
> > > > > > >
> > > > > > >   - @MigrationParameter
> > > > > > >   - @MigrationParameters
> > > > > > >   - @MigrateSetParameters
> > > > > > >
> > > > > > > Before we can deduplicate the code, it's fairly straightforward to
> > > > > > > deduplicate the comments first, so for each time we add a new migration
> > > > > > > parameter we don't need to copy the same paragraphs three times.
> > > > > > 
> > > > > > De-duplicating the code would be nice, but we haven't done so in years,
> > > > > > which suggests it's hard enough not to be worth the trouble.
> > > > > 
> > > > > The "MigrationParameter" enumeration isn't actually used in
> > > > > QMP at all.
> > > > > 
> > > > > It is only used in HMP for hmp_migrate_set_parameter and
> > > > > hmp_info_migrate_parameters. So it is questionable documenting
> > > > > that enum in the QMP reference docs at all.
> > > > > 
> > > > > 1c1
> > > > > < { 'struct': 'MigrationParameters',
> > > > > ---
> > > > > > { 'struct': 'MigrateSetParameters',
> > > > > 14,16c14,16
> > > > > <             '*tls-creds': 'str',
> > > > > <             '*tls-hostname': 'str',
> > > > > <             '*tls-authz': 'str',
> > > > > ---
> > > > > >             '*tls-creds': 'StrOrNull',
> > > > > >             '*tls-hostname': 'StrOrNull',
> > > > > >             '*tls-authz': 'StrOrNull',
> > > > > 
> > > > > Is it not valid to use StrOrNull in both cases and thus
> > > > > delete the duplication here ?
> > > > 
> > > > I tested removing MigrateSetParameters by replacing it with
> > > > MigrationParameters and it looks all fine here... I manually tested qmp/hmp
> > > > on set/query parameters, and qtests are all happy.
> > > 
> > > I meant the other way around, such we would be using 'StrOrNull'
> > > in all scenarios.
> > 
> > Yes, that should also work and even without worrying on nulls.  I just took
> > a random one replacing the other.
> > 
> > > 
> > > > 
> > > > The only thing I see that may affect it is we used to logically allow
> > > > taking things like '"tls-authz": null' in the json input, but now we won't
> > > > allow that because we'll be asking for a string type only.
> > > > 
> > > > Since we have query-qmp-schema I suppose we're all fine, because logically
> > > > the mgmt app (libvirt?) will still query that to understand the protocol,
> > > > so now we'll have (response of query-qmp-schema):
> > > > 
> > > >         {
> > > >             "arg-type": "144",
> > > >             "meta-type": "command",
> > > >             "name": "migrate-set-parameters",
> > > >             "ret-type": "0"
> > > >         },
> > > > 
> > > > Where 144 can start to point to MigrationParameters, rather than
> > > > MigrateSetParameters.
> > > > 
> > > > Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
> > > > fields when setting?  Funnily I tried it and actually anything that does
> > > > migrate-set-parameters with a "null" passed over to tls-* fields will
> > > > already crash qemu...
> > > > 
> > > > ./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.
> > > > 
> > > > #0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
> > > > #1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
> > > > #2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
> > > > #3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
> > > > #4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
> > > > #5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
> > > > #6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
> > > > #7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
> > > > #8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
> > > > #9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
> > > > #10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
> > > > #11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
> > > > #12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
> > > > #13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> > > > #14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
> > > > #15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
> > > > #16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
> > > > #17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
> > > > #18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
> > > > #19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48
> > > > 
> > > > Then I suppose it means all mgmt apps are not using "null" anyway, and it
> > > > makes more sense to me to just remove MigrateSetParameters (by replacing it
> > > > with MigrationParameters).
> > > 
> > > It shouldn't be crashing,  because qmp_migrate_set_parameters()
> > > is turning 'null' into  "", which means the assert ought to
> > > never fire. Did you have a local modiification that caused
> > > this crash perhaps ?
> > 
> > I think it just got overlooked when introducing tls-authz to not have added
> > that special code in qmp_migrate_set_parameters(), the other two are fine.
> 
> Oh right yes, pre-existing bug.

So do we really care about "null" in any form over "" (empty str) here for
tls-* parameters?

To fix this tls-authz bug we can add one more QTYPE_QNULL to QTYPE_QSTRING
convertion, but I'd rather just use "str" for all tls* fields and remove
the other two instead, if "null" is not important to anyone.

In all cases, I've appended with the two patches I'm currently testing
with.  It should also fix the tls-authz crash over 'null' by just rejecting
that.  But I'm open to anything - the patch (more than RFC) is more for
reference of whether we can drop the two objects in qapi/migration.

Thanks,

===8<===

From cd07ae2c048fe2265845bcf3f1ef4529854b71a1 Mon Sep 17 00:00:00 2001
From: Peter Xu <peterx@redhat.com>
Date: Fri, 4 Aug 2023 11:02:26 -0400
Subject: [PATCH 1/2] migration/qapi: Replace @MigrateSetParameters with
 @MigrationParameters
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

These two structs are mostly identical besides some fields (quote from
Daniel P. Berrangé in his reply):

1c1
< { 'struct': 'MigrationParameters',
---
> { 'struct': 'MigrateSetParameters',
14,16c14,16
<             '*tls-creds': 'str',
<             '*tls-hostname': 'str',
<             '*tls-authz': 'str',
---
>             '*tls-creds': 'StrOrNull',
>             '*tls-hostname': 'StrOrNull',
>             '*tls-authz': 'StrOrNull',

Here the difference is @MigrateSetParameters object would allow 'null'
values for any tls-* fields passed in.

Is that really important?  It seems not, because right now if anyone tries
to pass over a 'null' value to any of them, QEMU will already crash:

./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.

And it's actually important to fix this crash instead.

To fix it, we can either change the code to handle QTYPE_NULL, or rather we
can directly replace all @MigrateSetParameters references with
@MigrationParameters knowing that no user is anyway using 'null' as an
input.

This greatly deduplicates the code not only in qapi/migration.json, but
also in the generic migration code.

Signed-off-by: Peter Xu <peterx@redhat.com>
---
 qapi/migration.json            | 185 +--------------------------------
 migration/migration-hmp-cmds.c |  16 +--
 migration/options.c            | 140 ++-----------------------
 3 files changed, 12 insertions(+), 329 deletions(-)

diff --git a/qapi/migration.json b/qapi/migration.json
index 8843e74b59..0416da65b5 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -851,189 +851,6 @@
            { 'name': 'x-vcpu-dirty-limit-period', 'features': ['unstable'] },
            'vcpu-dirty-limit'] }
 
-##
-# @MigrateSetParameters:
-#
-# @announce-initial: Initial delay (in milliseconds) before sending
-#     the first announce (Since 4.0)
-#
-# @announce-max: Maximum delay (in milliseconds) between packets in
-#     the announcement (Since 4.0)
-#
-# @announce-rounds: Number of self-announce packets sent after
-#     migration (Since 4.0)
-#
-# @announce-step: Increase in delay (in milliseconds) between
-#     subsequent packets in the announcement (Since 4.0)
-#
-# @compress-level: compression level
-#
-# @compress-threads: compression thread count
-#
-# @compress-wait-thread: Controls behavior when all compression
-#     threads are currently busy.  If true (default), wait for a free
-#     compression thread to become available; otherwise, send the page
-#     uncompressed.  (Since 3.1)
-#
-# @decompress-threads: decompression thread count
-#
-# @throttle-trigger-threshold: The ratio of bytes_dirty_period and
-#     bytes_xfer_period to trigger throttling.  It is expressed as
-#     percentage.  The default value is 50. (Since 5.0)
-#
-# @cpu-throttle-initial: Initial percentage of time guest cpus are
-#     throttled when migration auto-converge is activated.  The
-#     default value is 20. (Since 2.7)
-#
-# @cpu-throttle-increment: throttle percentage increase each time
-#     auto-converge detects that migration is not making progress.
-#     The default value is 10. (Since 2.7)
-#
-# @cpu-throttle-tailslow: Make CPU throttling slower at tail stage At
-#     the tail stage of throttling, the Guest is very sensitive to CPU
-#     percentage while the @cpu-throttle -increment is excessive
-#     usually at tail stage.  If this parameter is true, we will
-#     compute the ideal CPU percentage used by the Guest, which may
-#     exactly make the dirty rate match the dirty rate threshold.
-#     Then we will choose a smaller throttle increment between the one
-#     specified by @cpu-throttle-increment and the one generated by
-#     ideal CPU percentage.  Therefore, it is compatible to
-#     traditional throttling, meanwhile the throttle increment won't
-#     be excessive at tail stage.  The default value is false.  (Since
-#     5.1)
-#
-# @tls-creds: ID of the 'tls-creds' object that provides credentials
-#     for establishing a TLS connection over the migration data
-#     channel.  On the outgoing side of the migration, the credentials
-#     must be for a 'client' endpoint, while for the incoming side the
-#     credentials must be for a 'server' endpoint.  Setting this to a
-#     non-empty string enables TLS for all migrations.  An empty
-#     string means that QEMU will use plain text mode for migration,
-#     rather than TLS (Since 2.9) Previously (since 2.7), this was
-#     reported by omitting tls-creds instead.
-#
-# @tls-hostname: hostname of the target host for the migration.  This
-#     is required when using x509 based TLS credentials and the
-#     migration URI does not already include a hostname.  For example
-#     if using fd: or exec: based migration, the hostname must be
-#     provided so that the server's x509 certificate identity can be
-#     validated.  (Since 2.7) An empty string means that QEMU will use
-#     the hostname associated with the migration URI, if any.  (Since
-#     2.9) Previously (since 2.7), this was reported by omitting
-#     tls-hostname instead.
-#
-# @max-bandwidth: to set maximum speed for migration.  maximum speed
-#     in bytes per second.  (Since 2.8)
-#
-# @downtime-limit: set maximum tolerated downtime for migration.
-#     maximum downtime in milliseconds (Since 2.8)
-#
-# @x-checkpoint-delay: the delay time between two COLO checkpoints.
-#     (Since 2.8)
-#
-# @block-incremental: Affects how much storage is migrated when the
-#     block migration capability is enabled.  When false, the entire
-#     storage backing chain is migrated into a flattened image at the
-#     destination; when true, only the active qcow2 layer is migrated
-#     and the destination must already have access to the same backing
-#     chain as was used on the source.  (since 2.10)
-#
-# @multifd-channels: Number of channels used to migrate data in
-#     parallel.  This is the same number that the number of sockets
-#     used for migration.  The default value is 2 (since 4.0)
-#
-# @xbzrle-cache-size: cache size to be used by XBZRLE migration.  It
-#     needs to be a multiple of the target page size and a power of 2
-#     (Since 2.11)
-#
-# @max-postcopy-bandwidth: Background transfer bandwidth during
-#     postcopy.  Defaults to 0 (unlimited).  In bytes per second.
-#     (Since 3.0)
-#
-# @max-cpu-throttle: maximum cpu throttle percentage.  The default
-#     value is 99. (Since 3.1)
-#
-# @multifd-compression: Which compression method to use.  Defaults to
-#     none.  (Since 5.0)
-#
-# @multifd-zlib-level: Set the compression level to be used in live
-#     migration, the compression level is an integer between 0 and 9,
-#     where 0 means no compression, 1 means the best compression
-#     speed, and 9 means best compression ratio which will consume
-#     more CPU. Defaults to 1. (Since 5.0)
-#
-# @multifd-zstd-level: Set the compression level to be used in live
-#     migration, the compression level is an integer between 0 and 20,
-#     where 0 means no compression, 1 means the best compression
-#     speed, and 20 means best compression ratio which will consume
-#     more CPU. Defaults to 1. (Since 5.0)
-#
-# @block-bitmap-mapping: Maps block nodes and bitmaps on them to
-#     aliases for the purpose of dirty bitmap migration.  Such aliases
-#     may for example be the corresponding names on the opposite site.
-#     The mapping must be one-to-one, but not necessarily complete: On
-#     the source, unmapped bitmaps and all bitmaps on unmapped nodes
-#     will be ignored.  On the destination, encountering an unmapped
-#     alias in the incoming migration stream will result in a report,
-#     and all further bitmap migration data will then be discarded.
-#     Note that the destination does not know about bitmaps it does
-#     not receive, so there is no limitation or requirement regarding
-#     the number of bitmaps received, or how they are named, or on
-#     which nodes they are placed.  By default (when this parameter
-#     has never been set), bitmap names are mapped to themselves.
-#     Nodes are mapped to their block device name if there is one, and
-#     to their node name otherwise.  (Since 5.2)
-#
-# @x-vcpu-dirty-limit-period: Periodic time (in milliseconds) of dirty
-#     limit during live migration.  Should be in the range 1 to 1000ms.
-#     Defaults to 1000ms.  (Since 8.1)
-#
-# @vcpu-dirty-limit: Dirtyrate limit (MB/s) during live migration.
-#     Defaults to 1.  (Since 8.1)
-#
-# Features:
-#
-# @unstable: Members @x-checkpoint-delay and @x-vcpu-dirty-limit-period
-#     are experimental.
-#
-# TODO: either fuse back into MigrationParameters, or make
-#     MigrationParameters members mandatory
-#
-# Since: 2.4
-##
-{ 'struct': 'MigrateSetParameters',
-  'data': { '*announce-initial': 'size',
-            '*announce-max': 'size',
-            '*announce-rounds': 'size',
-            '*announce-step': 'size',
-            '*compress-level': 'uint8',
-            '*compress-threads': 'uint8',
-            '*compress-wait-thread': 'bool',
-            '*decompress-threads': 'uint8',
-            '*throttle-trigger-threshold': 'uint8',
-            '*cpu-throttle-initial': 'uint8',
-            '*cpu-throttle-increment': 'uint8',
-            '*cpu-throttle-tailslow': 'bool',
-            '*tls-creds': 'StrOrNull',
-            '*tls-hostname': 'StrOrNull',
-            '*tls-authz': 'StrOrNull',
-            '*max-bandwidth': 'size',
-            '*downtime-limit': 'uint64',
-            '*x-checkpoint-delay': { 'type': 'uint32',
-                                     'features': [ 'unstable' ] },
-            '*block-incremental': 'bool',
-            '*multifd-channels': 'uint8',
-            '*xbzrle-cache-size': 'size',
-            '*max-postcopy-bandwidth': 'size',
-            '*max-cpu-throttle': 'uint8',
-            '*multifd-compression': 'MultiFDCompression',
-            '*multifd-zlib-level': 'uint8',
-            '*multifd-zstd-level': 'uint8',
-            '*block-bitmap-mapping': [ 'BitmapMigrationNodeAlias' ],
-            '*x-vcpu-dirty-limit-period': { 'type': 'uint64',
-                                            'features': [ 'unstable' ] },
-            '*vcpu-dirty-limit': 'uint64'} }
-
 ##
 # @migrate-set-parameters:
 #
@@ -1048,7 +865,7 @@
 # <- { "return": {} }
 ##
 { 'command': 'migrate-set-parameters', 'boxed': true,
-  'data': 'MigrateSetParameters' }
+  'data': 'MigrationParameters' }
 
 ##
 # @MigrationParameters:
diff --git a/migration/migration-hmp-cmds.c b/migration/migration-hmp-cmds.c
index c115ef2d23..a64672f640 100644
--- a/migration/migration-hmp-cmds.c
+++ b/migration/migration-hmp-cmds.c
@@ -497,7 +497,7 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict)
     const char *param = qdict_get_str(qdict, "parameter");
     const char *valuestr = qdict_get_str(qdict, "value");
     Visitor *v = string_input_visitor_new(valuestr);
-    MigrateSetParameters *p = g_new0(MigrateSetParameters, 1);
+    MigrationParameters *p = g_new0(MigrationParameters, 1);
     uint64_t valuebw = 0;
     uint64_t cache_size;
     Error *err = NULL;
@@ -546,19 +546,13 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict)
         visit_type_uint8(v, param, &p->max_cpu_throttle, &err);
         break;
     case MIGRATION_PARAMETER_TLS_CREDS:
-        p->tls_creds = g_new0(StrOrNull, 1);
-        p->tls_creds->type = QTYPE_QSTRING;
-        visit_type_str(v, param, &p->tls_creds->u.s, &err);
+        visit_type_str(v, param, &p->tls_creds, &err);
         break;
     case MIGRATION_PARAMETER_TLS_HOSTNAME:
-        p->tls_hostname = g_new0(StrOrNull, 1);
-        p->tls_hostname->type = QTYPE_QSTRING;
-        visit_type_str(v, param, &p->tls_hostname->u.s, &err);
+        visit_type_str(v, param, &p->tls_hostname, &err);
         break;
     case MIGRATION_PARAMETER_TLS_AUTHZ:
-        p->tls_authz = g_new0(StrOrNull, 1);
-        p->tls_authz->type = QTYPE_QSTRING;
-        visit_type_str(v, param, &p->tls_authz->u.s, &err);
+        visit_type_str(v, param, &p->tls_authz, &err);
         break;
     case MIGRATION_PARAMETER_MAX_BANDWIDTH:
         p->has_max_bandwidth = true;
@@ -657,7 +651,7 @@ void hmp_migrate_set_parameter(Monitor *mon, const QDict *qdict)
     qmp_migrate_set_parameters(p, &err);
 
  cleanup:
-    qapi_free_MigrateSetParameters(p);
+    qapi_free_MigrationParameters(p);
     visit_free(v);
     hmp_handle_error(mon, err);
 }
diff --git a/migration/options.c b/migration/options.c
index 1d1e1321b0..7967c572fc 100644
--- a/migration/options.c
+++ b/migration/options.c
@@ -1172,113 +1172,7 @@ bool migrate_params_check(MigrationParameters *params, Error **errp)
     return true;
 }
 
-static void migrate_params_test_apply(MigrateSetParameters *params,
-                                      MigrationParameters *dest)
-{
-    *dest = migrate_get_current()->parameters;
-
-    /* TODO use QAPI_CLONE() instead of duplicating it inline */
-
-    if (params->has_compress_level) {
-        dest->compress_level = params->compress_level;
-    }
-
-    if (params->has_compress_threads) {
-        dest->compress_threads = params->compress_threads;
-    }
-
-    if (params->has_compress_wait_thread) {
-        dest->compress_wait_thread = params->compress_wait_thread;
-    }
-
-    if (params->has_decompress_threads) {
-        dest->decompress_threads = params->decompress_threads;
-    }
-
-    if (params->has_throttle_trigger_threshold) {
-        dest->throttle_trigger_threshold = params->throttle_trigger_threshold;
-    }
-
-    if (params->has_cpu_throttle_initial) {
-        dest->cpu_throttle_initial = params->cpu_throttle_initial;
-    }
-
-    if (params->has_cpu_throttle_increment) {
-        dest->cpu_throttle_increment = params->cpu_throttle_increment;
-    }
-
-    if (params->has_cpu_throttle_tailslow) {
-        dest->cpu_throttle_tailslow = params->cpu_throttle_tailslow;
-    }
-
-    if (params->tls_creds) {
-        assert(params->tls_creds->type == QTYPE_QSTRING);
-        dest->tls_creds = params->tls_creds->u.s;
-    }
-
-    if (params->tls_hostname) {
-        assert(params->tls_hostname->type == QTYPE_QSTRING);
-        dest->tls_hostname = params->tls_hostname->u.s;
-    }
-
-    if (params->has_max_bandwidth) {
-        dest->max_bandwidth = params->max_bandwidth;
-    }
-
-    if (params->has_downtime_limit) {
-        dest->downtime_limit = params->downtime_limit;
-    }
-
-    if (params->has_x_checkpoint_delay) {
-        dest->x_checkpoint_delay = params->x_checkpoint_delay;
-    }
-
-    if (params->has_block_incremental) {
-        dest->block_incremental = params->block_incremental;
-    }
-    if (params->has_multifd_channels) {
-        dest->multifd_channels = params->multifd_channels;
-    }
-    if (params->has_multifd_compression) {
-        dest->multifd_compression = params->multifd_compression;
-    }
-    if (params->has_xbzrle_cache_size) {
-        dest->xbzrle_cache_size = params->xbzrle_cache_size;
-    }
-    if (params->has_max_postcopy_bandwidth) {
-        dest->max_postcopy_bandwidth = params->max_postcopy_bandwidth;
-    }
-    if (params->has_max_cpu_throttle) {
-        dest->max_cpu_throttle = params->max_cpu_throttle;
-    }
-    if (params->has_announce_initial) {
-        dest->announce_initial = params->announce_initial;
-    }
-    if (params->has_announce_max) {
-        dest->announce_max = params->announce_max;
-    }
-    if (params->has_announce_rounds) {
-        dest->announce_rounds = params->announce_rounds;
-    }
-    if (params->has_announce_step) {
-        dest->announce_step = params->announce_step;
-    }
-
-    if (params->has_block_bitmap_mapping) {
-        dest->has_block_bitmap_mapping = true;
-        dest->block_bitmap_mapping = params->block_bitmap_mapping;
-    }
-
-    if (params->has_x_vcpu_dirty_limit_period) {
-        dest->x_vcpu_dirty_limit_period =
-            params->x_vcpu_dirty_limit_period;
-    }
-    if (params->has_vcpu_dirty_limit) {
-        dest->vcpu_dirty_limit = params->vcpu_dirty_limit;
-    }
-}
-
-static void migrate_params_apply(MigrateSetParameters *params, Error **errp)
+static void migrate_params_apply(MigrationParameters *params, Error **errp)
 {
     MigrationState *s = migrate_get_current();
 
@@ -1318,20 +1212,17 @@ static void migrate_params_apply(MigrateSetParameters *params, Error **errp)
 
     if (params->tls_creds) {
         g_free(s->parameters.tls_creds);
-        assert(params->tls_creds->type == QTYPE_QSTRING);
-        s->parameters.tls_creds = g_strdup(params->tls_creds->u.s);
+        s->parameters.tls_creds = g_strdup(params->tls_creds);
     }
 
     if (params->tls_hostname) {
         g_free(s->parameters.tls_hostname);
-        assert(params->tls_hostname->type == QTYPE_QSTRING);
-        s->parameters.tls_hostname = g_strdup(params->tls_hostname->u.s);
+        s->parameters.tls_hostname = g_strdup(params->tls_hostname);
     }
 
     if (params->tls_authz) {
         g_free(s->parameters.tls_authz);
-        assert(params->tls_authz->type == QTYPE_QSTRING);
-        s->parameters.tls_authz = g_strdup(params->tls_authz->u.s);
+        s->parameters.tls_authz = g_strdup(params->tls_authz);
     }
 
     if (params->has_max_bandwidth) {
@@ -1404,28 +1295,9 @@ static void migrate_params_apply(MigrateSetParameters *params, Error **errp)
     }
 }
 
-void qmp_migrate_set_parameters(MigrateSetParameters *params, Error **errp)
+void qmp_migrate_set_parameters(MigrationParameters *params, Error **errp)
 {
-    MigrationParameters tmp;
-
-    /* TODO Rewrite "" to null instead */
-    if (params->tls_creds
-        && params->tls_creds->type == QTYPE_QNULL) {
-        qobject_unref(params->tls_creds->u.n);
-        params->tls_creds->type = QTYPE_QSTRING;
-        params->tls_creds->u.s = strdup("");
-    }
-    /* TODO Rewrite "" to null instead */
-    if (params->tls_hostname
-        && params->tls_hostname->type == QTYPE_QNULL) {
-        qobject_unref(params->tls_hostname->u.n);
-        params->tls_hostname->type = QTYPE_QSTRING;
-        params->tls_hostname->u.s = strdup("");
-    }
-
-    migrate_params_test_apply(params, &tmp);
-
-    if (!migrate_params_check(&tmp, errp)) {
+    if (!migrate_params_check(params, errp)) {
         /* Invalid parameter */
         return;
     }

Peter Xu <peterx@redhat.com> writes:

> On Fri, Aug 04, 2023 at 05:48:49PM +0100, Daniel P. Berrangé wrote:
>> On Fri, Aug 04, 2023 at 12:46:18PM -0400, Peter Xu wrote:
>> > On Fri, Aug 04, 2023 at 05:29:19PM +0100, Daniel P. Berrangé wrote:
>> > > On Fri, Aug 04, 2023 at 12:01:54PM -0400, Peter Xu wrote:
>> > > > On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
>> > > > > On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
>> > > > > > Peter Xu <peterx@redhat.com> writes:
>> > > > > > 
>> > > > > > > We used to have three objects that have always the same list of parameters
>> > > > > > 
>> > > > > > We have!
>> > > > > > 
>> > > > > > > and comments are always duplicated:
>> > > > > > >
>> > > > > > >   - @MigrationParameter
>> > > > > > >   - @MigrationParameters
>> > > > > > >   - @MigrateSetParameters
>> > > > > > >
>> > > > > > > Before we can deduplicate the code, it's fairly straightforward to
>> > > > > > > deduplicate the comments first, so for each time we add a new migration
>> > > > > > > parameter we don't need to copy the same paragraphs three times.
>> > > > > > 
>> > > > > > De-duplicating the code would be nice, but we haven't done so in years,
>> > > > > > which suggests it's hard enough not to be worth the trouble.
>> > > > > 
>> > > > > The "MigrationParameter" enumeration isn't actually used in
>> > > > > QMP at all.
>> > > > > 
>> > > > > It is only used in HMP for hmp_migrate_set_parameter and
>> > > > > hmp_info_migrate_parameters. So it is questionable documenting
>> > > > > that enum in the QMP reference docs at all.
>> > > > > 
>> > > > > 1c1
>> > > > > < { 'struct': 'MigrationParameters',
>> > > > > ---
>> > > > > > { 'struct': 'MigrateSetParameters',
>> > > > > 14,16c14,16
>> > > > > <             '*tls-creds': 'str',
>> > > > > <             '*tls-hostname': 'str',
>> > > > > <             '*tls-authz': 'str',
>> > > > > ---
>> > > > > >             '*tls-creds': 'StrOrNull',
>> > > > > >             '*tls-hostname': 'StrOrNull',
>> > > > > >             '*tls-authz': 'StrOrNull',
>> > > > > 
>> > > > > Is it not valid to use StrOrNull in both cases and thus
>> > > > > delete the duplication here ?
>> > > > 
>> > > > I tested removing MigrateSetParameters by replacing it with
>> > > > MigrationParameters and it looks all fine here... I manually tested qmp/hmp
>> > > > on set/query parameters, and qtests are all happy.
>> > > 
>> > > I meant the other way around, such we would be using 'StrOrNull'
>> > > in all scenarios.
>> > 
>> > Yes, that should also work and even without worrying on nulls.  I just took
>> > a random one replacing the other.
>> > 
>> > > 
>> > > > 
>> > > > The only thing I see that may affect it is we used to logically allow
>> > > > taking things like '"tls-authz": null' in the json input, but now we won't
>> > > > allow that because we'll be asking for a string type only.
>> > > > 
>> > > > Since we have query-qmp-schema I suppose we're all fine, because logically
>> > > > the mgmt app (libvirt?) will still query that to understand the protocol,
>> > > > so now we'll have (response of query-qmp-schema):
>> > > > 
>> > > >         {
>> > > >             "arg-type": "144",
>> > > >             "meta-type": "command",
>> > > >             "name": "migrate-set-parameters",
>> > > >             "ret-type": "0"
>> > > >         },
>> > > > 
>> > > > Where 144 can start to point to MigrationParameters, rather than
>> > > > MigrateSetParameters.
>> > > > 
>> > > > Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
>> > > > fields when setting?  Funnily I tried it and actually anything that does
>> > > > migrate-set-parameters with a "null" passed over to tls-* fields will
>> > > > already crash qemu...
>> > > > 
>> > > > ./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.
>> > > > 
>> > > > #0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
>> > > > #1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
>> > > > #2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
>> > > > #3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
>> > > > #4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
>> > > > #5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
>> > > > #6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
>> > > > #7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
>> > > > #8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
>> > > > #9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
>> > > > #10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
>> > > > #11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
>> > > > #12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
>> > > > #13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
>> > > > #14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
>> > > > #15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
>> > > > #16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
>> > > > #17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
>> > > > #18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
>> > > > #19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48
>> > > > 
>> > > > Then I suppose it means all mgmt apps are not using "null" anyway, and it
>> > > > makes more sense to me to just remove MigrateSetParameters (by replacing it
>> > > > with MigrationParameters).
>> > > 
>> > > It shouldn't be crashing,  because qmp_migrate_set_parameters()
>> > > is turning 'null' into  "", which means the assert ought to
>> > > never fire. Did you have a local modiification that caused
>> > > this crash perhaps ?
>> > 
>> > I think it just got overlooked when introducing tls-authz to not have added
>> > that special code in qmp_migrate_set_parameters(), the other two are fine.
>> 
>> Oh right yes, pre-existing bug.
>
> So do we really care about "null" in any form over "" (empty str) here for
> tls-* parameters?

In my opinion, the use of "" was a design mistake.  Here's my argument:

commit 01fa55982692fb51a16049b63b571651a1053989
Author: Markus Armbruster <armbru@redhat.com>
Date:   Tue Jul 18 14:42:04 2017 +0200

    migration: Use JSON null instead of "" to reset parameter to default
    
    migrate-set-parameters sets migration parameters according to is
    arguments like this:
    
    * Present means "set the parameter to this value"
    
    * Absent means "leave the parameter unchanged"
    
    * Except for parameters tls_creds and tls_hostname, "" means "reset
      the parameter to its default value
    
    The first two are perfectly normal: presence of the parameter makes
    the command do something.
    
    The third one overloads the parameter with a second meaning.  The
    overloading is *implicit*, i.e. it's not visible in the types.  Works
    here, because "" is neither a valid TLS credentials ID, nor a valid
    host name.
    
    Pressing argument values the schema accepts, but are semantically
    invalid, into service to mean "reset to default" is not general, as
    suitable invalid values need not exist.  I also find it ugly.
    
    To clean this up, we could add a separate flag argument to ask for
    "reset to default", or add a distinct value to @tls_creds and
    @tls_hostname.  This commit implements the latter: add JSON null to
    the values of @tls_creds and @tls_hostname, deprecate "".
    
    Because we're so close to the 2.10 freeze, implement it in the
    stupidest way possible: have qmp_migrate_set_parameters() rewrite null
    to "" before anything else can see the null.  The proper way to do it
    would be rewriting "" to null, but that requires fixing up code to
    work with null.  Add TODO comments for that.
    
    Signed-off-by: Markus Armbruster <armbru@redhat.com>
    Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>

> To fix this tls-authz bug we can add one more QTYPE_QNULL to QTYPE_QSTRING
> convertion, but I'd rather just use "str" for all tls* fields and remove
> the other two instead, if "null" is not important to anyone.

"Important" sounds too much like absolutes :)

I think we have a tradeoff here.  If perpetuating the unclean and ugly
use of "" is what it takes to de-triplicate migration parameters, we may
decide to accept that.

> In all cases, I've appended with the two patches I'm currently testing
> with.  It should also fix the tls-authz crash over 'null' by just rejecting
> that.  But I'm open to anything - the patch (more than RFC) is more for
> reference of whether we can drop the two objects in qapi/migration.
>
> Thanks,

On Sat, Aug 05, 2023 at 10:12:00AM +0200, Markus Armbruster wrote:
> Peter Xu <peterx@redhat.com> writes:
> 
> > On Fri, Aug 04, 2023 at 05:48:49PM +0100, Daniel P. Berrangé wrote:
> >> On Fri, Aug 04, 2023 at 12:46:18PM -0400, Peter Xu wrote:
> >> > On Fri, Aug 04, 2023 at 05:29:19PM +0100, Daniel P. Berrangé wrote:
> >> > > On Fri, Aug 04, 2023 at 12:01:54PM -0400, Peter Xu wrote:
> >> > > > On Fri, Aug 04, 2023 at 02:59:07PM +0100, Daniel P. Berrangé wrote:
> >> > > > > On Fri, Aug 04, 2023 at 02:28:05PM +0200, Markus Armbruster wrote:
> >> > > > > > Peter Xu <peterx@redhat.com> writes:
> >> > > > > > 
> >> > > > > > > We used to have three objects that have always the same list of parameters
> >> > > > > > 
> >> > > > > > We have!
> >> > > > > > 
> >> > > > > > > and comments are always duplicated:
> >> > > > > > >
> >> > > > > > >   - @MigrationParameter
> >> > > > > > >   - @MigrationParameters
> >> > > > > > >   - @MigrateSetParameters
> >> > > > > > >
> >> > > > > > > Before we can deduplicate the code, it's fairly straightforward to
> >> > > > > > > deduplicate the comments first, so for each time we add a new migration
> >> > > > > > > parameter we don't need to copy the same paragraphs three times.
> >> > > > > > 
> >> > > > > > De-duplicating the code would be nice, but we haven't done so in years,
> >> > > > > > which suggests it's hard enough not to be worth the trouble.
> >> > > > > 
> >> > > > > The "MigrationParameter" enumeration isn't actually used in
> >> > > > > QMP at all.
> >> > > > > 
> >> > > > > It is only used in HMP for hmp_migrate_set_parameter and
> >> > > > > hmp_info_migrate_parameters. So it is questionable documenting
> >> > > > > that enum in the QMP reference docs at all.
> >> > > > > 
> >> > > > > 1c1
> >> > > > > < { 'struct': 'MigrationParameters',
> >> > > > > ---
> >> > > > > > { 'struct': 'MigrateSetParameters',
> >> > > > > 14,16c14,16
> >> > > > > <             '*tls-creds': 'str',
> >> > > > > <             '*tls-hostname': 'str',
> >> > > > > <             '*tls-authz': 'str',
> >> > > > > ---
> >> > > > > >             '*tls-creds': 'StrOrNull',
> >> > > > > >             '*tls-hostname': 'StrOrNull',
> >> > > > > >             '*tls-authz': 'StrOrNull',
> >> > > > > 
> >> > > > > Is it not valid to use StrOrNull in both cases and thus
> >> > > > > delete the duplication here ?
> >> > > > 
> >> > > > I tested removing MigrateSetParameters by replacing it with
> >> > > > MigrationParameters and it looks all fine here... I manually tested qmp/hmp
> >> > > > on set/query parameters, and qtests are all happy.
> >> > > 
> >> > > I meant the other way around, such we would be using 'StrOrNull'
> >> > > in all scenarios.
> >> > 
> >> > Yes, that should also work and even without worrying on nulls.  I just took
> >> > a random one replacing the other.
> >> > 
> >> > > 
> >> > > > 
> >> > > > The only thing I see that may affect it is we used to logically allow
> >> > > > taking things like '"tls-authz": null' in the json input, but now we won't
> >> > > > allow that because we'll be asking for a string type only.
> >> > > > 
> >> > > > Since we have query-qmp-schema I suppose we're all fine, because logically
> >> > > > the mgmt app (libvirt?) will still query that to understand the protocol,
> >> > > > so now we'll have (response of query-qmp-schema):
> >> > > > 
> >> > > >         {
> >> > > >             "arg-type": "144",
> >> > > >             "meta-type": "command",
> >> > > >             "name": "migrate-set-parameters",
> >> > > >             "ret-type": "0"
> >> > > >         },
> >> > > > 
> >> > > > Where 144 can start to point to MigrationParameters, rather than
> >> > > > MigrateSetParameters.
> >> > > > 
> >> > > > Ok, then what if the mgmt app doesn't care and just used "null" in tls-*
> >> > > > fields when setting?  Funnily I tried it and actually anything that does
> >> > > > migrate-set-parameters with a "null" passed over to tls-* fields will
> >> > > > already crash qemu...
> >> > > > 
> >> > > > ./migration/options.c:1333: migrate_params_apply: Assertion `params->tls_authz->type == QTYPE_QSTRING' failed.
> >> > > > 
> >> > > > #0  0x00007f72f4b2a844 in __pthread_kill_implementation () at /lib64/libc.so.6
> >> > > > #1  0x00007f72f4ad9abe in raise () at /lib64/libc.so.6
> >> > > > #2  0x00007f72f4ac287f in abort () at /lib64/libc.so.6
> >> > > > #3  0x00007f72f4ac279b in _nl_load_domain.cold () at /lib64/libc.so.6
> >> > > > #4  0x00007f72f4ad2147 in  () at /lib64/libc.so.6
> >> > > > #5  0x00005573308740e6 in migrate_params_apply (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1333
> >> > > > #6  0x0000557330874591 in qmp_migrate_set_parameters (params=0x7ffc74fd09d0, errp=0x7ffc74fd0998) at ../migration/options.c:1433
> >> > > > #7  0x0000557330cb9132 in qmp_marshal_migrate_set_parameters (args=0x7f72e00036d0, ret=0x7f72f133cd98, errp=0x7f72f133cd90) at qapi/qapi-commands-migration.c:214
> >> > > > #8  0x0000557330d07fab in do_qmp_dispatch_bh (opaque=0x7f72f133ce30) at ../qapi/qmp-dispatch.c:128
> >> > > > #9  0x0000557330d33bbb in aio_bh_call (bh=0x5573337d7920) at ../util/async.c:169
> >> > > > #10 0x0000557330d33cd8 in aio_bh_poll (ctx=0x55733356e7d0) at ../util/async.c:216
> >> > > > #11 0x0000557330d17a19 in aio_dispatch (ctx=0x55733356e7d0) at ../util/aio-posix.c:423
> >> > > > #12 0x0000557330d34117 in aio_ctx_dispatch (source=0x55733356e7d0, callback=0x0, user_data=0x0) at ../util/async.c:358
> >> > > > #13 0x00007f72f5a8848c in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> >> > > > #14 0x0000557330d358d4 in glib_pollfds_poll () at ../util/main-loop.c:290
> >> > > > #15 0x0000557330d35951 in os_host_main_loop_wait (timeout=0) at ../util/main-loop.c:313
> >> > > > #16 0x0000557330d35a5f in main_loop_wait (nonblocking=0) at ../util/main-loop.c:592
> >> > > > #17 0x000055733083aee0 in qemu_main_loop () at ../softmmu/runstate.c:732
> >> > > > #18 0x0000557330b0921b in qemu_default_main () at ../softmmu/main.c:37
> >> > > > #19 0x0000557330b09251 in main (argc=35, argv=0x7ffc74fd0ec8) at ../softmmu/main.c:48
> >> > > > 
> >> > > > Then I suppose it means all mgmt apps are not using "null" anyway, and it
> >> > > > makes more sense to me to just remove MigrateSetParameters (by replacing it
> >> > > > with MigrationParameters).
> >> > > 
> >> > > It shouldn't be crashing,  because qmp_migrate_set_parameters()
> >> > > is turning 'null' into  "", which means the assert ought to
> >> > > never fire. Did you have a local modiification that caused
> >> > > this crash perhaps ?
> >> > 
> >> > I think it just got overlooked when introducing tls-authz to not have added
> >> > that special code in qmp_migrate_set_parameters(), the other two are fine.
> >> 
> >> Oh right yes, pre-existing bug.
> >
> > So do we really care about "null" in any form over "" (empty str) here for
> > tls-* parameters?
> 
> In my opinion, the use of "" was a design mistake.  Here's my argument:
> 
> commit 01fa55982692fb51a16049b63b571651a1053989
> Author: Markus Armbruster <armbru@redhat.com>
> Date:   Tue Jul 18 14:42:04 2017 +0200
> 
>     migration: Use JSON null instead of "" to reset parameter to default
>     
>     migrate-set-parameters sets migration parameters according to is
>     arguments like this:
>     
>     * Present means "set the parameter to this value"
>     
>     * Absent means "leave the parameter unchanged"
>     
>     * Except for parameters tls_creds and tls_hostname, "" means "reset
>       the parameter to its default value
>     
>     The first two are perfectly normal: presence of the parameter makes
>     the command do something.
>     
>     The third one overloads the parameter with a second meaning.  The
>     overloading is *implicit*, i.e. it's not visible in the types.  Works
>     here, because "" is neither a valid TLS credentials ID, nor a valid
>     host name.
>     
>     Pressing argument values the schema accepts, but are semantically
>     invalid, into service to mean "reset to default" is not general, as
>     suitable invalid values need not exist.  I also find it ugly.
>     
>     To clean this up, we could add a separate flag argument to ask for
>     "reset to default", or add a distinct value to @tls_creds and
>     @tls_hostname.  This commit implements the latter: add JSON null to
>     the values of @tls_creds and @tls_hostname, deprecate "".
>     
>     Because we're so close to the 2.10 freeze, implement it in the
>     stupidest way possible: have qmp_migrate_set_parameters() rewrite null
>     to "" before anything else can see the null.  The proper way to do it
>     would be rewriting "" to null, but that requires fixing up code to
>     work with null.  Add TODO comments for that.
>     
>     Signed-off-by: Markus Armbruster <armbru@redhat.com>
>     Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
>     Reviewed-by: Eric Blake <eblake@redhat.com>

I see.  Personally I think as long as the interface is 100% clear I'll be
all fine (say, no possible misuse of "").  But keeping StrOrNull may
definitely be cleaner I guess.

> 
> > To fix this tls-authz bug we can add one more QTYPE_QNULL to QTYPE_QSTRING
> > convertion, but I'd rather just use "str" for all tls* fields and remove
> > the other two instead, if "null" is not important to anyone.
> 
> "Important" sounds too much like absolutes :)
> 
> I think we have a tradeoff here.  If perpetuating the unclean and ugly
> use of "" is what it takes to de-triplicate migration parameters, we may
> decide to accept that.

I don't think it's a must.  As Dan raised, we can convert str -> StrOrNull
for MigrationParameters. I assume it won't affect query-migrate-parameters
anyway OTOH.

I assume it means there's nothing yet obvious that we overlooked on the
whole idea.  Let me propose the formal patchset early next week.  It'll be
mostly the patch I attached but just add those extra logics for StrOrNull,
so the diffstat might be less attractive but hopefully still good enough to
be accepted.

Thanks,

On Sun, Aug 06, 2023 at 11:49:46AM -0400, Peter Xu wrote:
> > I think we have a tradeoff here.  If perpetuating the unclean and ugly
> > use of "" is what it takes to de-triplicate migration parameters, we may
> > decide to accept that.
> 
> I don't think it's a must.  As Dan raised, we can convert str -> StrOrNull
> for MigrationParameters. I assume it won't affect query-migrate-parameters
> anyway OTOH.
> 
> I assume it means there's nothing yet obvious that we overlooked on the
> whole idea.  Let me propose the formal patchset early next week.  It'll be
> mostly the patch I attached but just add those extra logics for StrOrNull,
> so the diffstat might be less attractive but hopefully still good enough to
> be accepted.

The new StrOrNull approach doesn't work with current migration object
properties.. as StrOrNull must be a pointer for @MigrationParameters not
static, and it stops working with offsetof():

../migration/options.c:218:5: error: cannot apply ‘offsetof’ to a non constant address
  218 |     DEFINE_PROP_STRING("tls-creds", MigrationState, parameters.tls_creds->u.s),
      |     ^~~~~~~~~~~~~~~~~~
../migration/options.c:219:5: error: cannot apply ‘offsetof’ to a non constant address
  219 |     DEFINE_PROP_STRING("tls-hostname", MigrationState, parameters.tls_hostname->u.s),
      |     ^~~~~~~~~~~~~~~~~~
../migration/options.c:220:5: error: cannot apply ‘offsetof’ to a non constant address
  220 |     DEFINE_PROP_STRING("tls-authz", MigrationState, parameters.tls_authz->u.s),
      |     ^~~~~~~~~~~~~~~~~~

Any easy way to fix this?  I.e., is there a way to declare StrOrNull (in
MigrationParameters of qapi/migration.json) to be statically allocated
rather than a pointer (just like default behavior of any uint* types)?

Thanks,

On Tue, Aug 08, 2023 at 04:03:46PM -0400, Peter Xu wrote:
> On Sun, Aug 06, 2023 at 11:49:46AM -0400, Peter Xu wrote:
> > > I think we have a tradeoff here.  If perpetuating the unclean and ugly
> > > use of "" is what it takes to de-triplicate migration parameters, we may
> > > decide to accept that.
> > 
> > I don't think it's a must.  As Dan raised, we can convert str -> StrOrNull
> > for MigrationParameters. I assume it won't affect query-migrate-parameters
> > anyway OTOH.
> > 
> > I assume it means there's nothing yet obvious that we overlooked on the
> > whole idea.  Let me propose the formal patchset early next week.  It'll be
> > mostly the patch I attached but just add those extra logics for StrOrNull,
> > so the diffstat might be less attractive but hopefully still good enough to
> > be accepted.
> 
> The new StrOrNull approach doesn't work with current migration object
> properties.. as StrOrNull must be a pointer for @MigrationParameters not
> static, and it stops working with offsetof():
> 
> ../migration/options.c:218:5: error: cannot apply ‘offsetof’ to a non constant address
>   218 |     DEFINE_PROP_STRING("tls-creds", MigrationState, parameters.tls_creds->u.s),
>       |     ^~~~~~~~~~~~~~~~~~
> ../migration/options.c:219:5: error: cannot apply ‘offsetof’ to a non constant address
>   219 |     DEFINE_PROP_STRING("tls-hostname", MigrationState, parameters.tls_hostname->u.s),
>       |     ^~~~~~~~~~~~~~~~~~
> ../migration/options.c:220:5: error: cannot apply ‘offsetof’ to a non constant address
>   220 |     DEFINE_PROP_STRING("tls-authz", MigrationState, parameters.tls_authz->u.s),
>       |     ^~~~~~~~~~~~~~~~~~
> 
> Any easy way to fix this?  I.e., is there a way to declare StrOrNull (in
> MigrationParameters of qapi/migration.json) to be statically allocated
> rather than a pointer (just like default behavior of any uint* types)?

Posted a version with 'str' replacing 'StrOrNull'.  Let's move the
discussion there:

https://lore.kernel.org/r/20230814221947.353093-1-peterx@redhat.com