From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, Zhiyi Guo <zhguo@redhat.com>,
Leonardo Bras Soares Passos <lsoaresp@redhat.com>,
Fabiano Rosas <farosas@suse.de>,
Juan Quintela <quintela@redhat.com>,
Eric Blake <eblake@redhat.com>,
Chensheng Dong <chdong@redhat.com>
Subject: Re: [PATCH for-8.2 v2 1/2] qapi/migration: Deduplicate migration parameter field comments
Date: Fri, 4 Aug 2023 12:46:18 -0400 [thread overview]
Message-ID: <ZM0rWiHF8voqOdyp@x1n> (raw)
In-Reply-To: <ZM0nX8qt1T3aZgNK@redhat.com>
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,
--
Peter Xu
next prev parent reply other threads:[~2023-08-04 16:47 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-03 15:53 [PATCH for-8.2 v2 0/2] migration: Add max-switchover-bandwidth parameter Peter Xu
2023-08-03 15:53 ` [PATCH for-8.2 v2 1/2] qapi/migration: Deduplicate migration parameter field comments Peter Xu
2023-08-04 12:28 ` Markus Armbruster
2023-08-04 13:59 ` Daniel P. Berrangé
2023-08-04 16:01 ` Peter Xu
2023-08-04 16:29 ` Daniel P. Berrangé
2023-08-04 16:46 ` Peter Xu [this message]
2023-08-04 16:48 ` Daniel P. Berrangé
2023-08-04 21:02 ` Peter Xu
2023-08-05 8:12 ` Markus Armbruster
2023-08-06 15:49 ` Peter Xu
2023-08-08 20:03 ` Peter Xu
2023-08-14 22:24 ` Peter Xu
2023-08-03 15:53 ` [PATCH for-8.2 v2 2/2] migration: Allow user to specify migration switchover bandwidth Peter Xu
2023-08-31 18:14 ` Joao Martins
2023-08-31 18:34 ` Peter Xu
2023-09-01 6:55 ` Wang, Lei
2023-09-01 8:37 ` Daniel P. Berrangé
2023-09-01 14:40 ` Peter Xu
2023-09-05 16:46 ` Peter Xu
2023-09-05 17:39 ` Daniel P. Berrangé
2023-09-06 2:27 ` Wang, Lei
2023-09-01 17:59 ` Joao Martins
2023-09-01 18:39 ` Joao Martins
2023-09-05 15:31 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZM0rWiHF8voqOdyp@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=chdong@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=lsoaresp@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhguo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.