| Message ID | 20230803155344.11450-2-peterx@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | migration: Add max-switchover-bandwidth parameter | expand |
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
diff --git a/qapi/migration.json b/qapi/migration.json index 8843e74b59..bb798f87a5 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -854,142 +854,9 @@ ## # @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) +# Object structure to set migration parameters. For detailed +# explanation of each of the field, please refer to the documentation +# of @MigrationParameter. # # Features: # @@ -1053,146 +920,10 @@ ## # @MigrationParameters: # -# The optional members aren't actually optional. -# -# @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. (Since -# 2.7) -# -# @cpu-throttle-increment: throttle percentage increase each time -# auto-converge detects that migration is not making progress. -# (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. An empty string -# means that QEMU will use plain text mode for migration, rather -# than TLS (Since 2.7) Note: 2.8 reports this 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) Note: 2.8 reports this by omitting tls-hostname instead. -# -# @tls-authz: ID of the 'authz' object subclass that provides access -# control checking of the TLS x509 certificate distinguished name. -# (Since 4.0) -# -# @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. Defaults to 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) +# 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. # # Features: #
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(-)