[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V4 09/19] migration: incoming channel
From: |
Peter Xu |
Subject: |
Re: [PATCH V4 09/19] migration: incoming channel |
Date: |
Mon, 9 Dec 2024 11:36:58 -0500 |
On Mon, Dec 09, 2024 at 01:12:25PM +0100, Markus Armbruster wrote:
> >>> @@ -2730,7 +2761,7 @@ void qmp_x_exit_preconfig(Error **errp)
> >>> if (incoming) {
> >>> Error *local_err = NULL;
> >>> if (strcmp(incoming, "defer") != 0) {
> >>> - qmp_migrate_incoming(incoming, false, NULL, true, true,
> >>> + qmp_migrate_incoming(NULL, true, incoming_channels, true,
> >>> true,
> >>> &local_err);
> >>
> >> You move the parsing of legacy URI from within qmp_migrate_incoming()
> >> into incoming_option_parse().
> >>
> >> The alternative is not to parse it in incoming_option_parse(), but pass
> >> it to qmp_migrate_incoming() like this:
> >>
> >> qmp_migrate_incoming(incoming, !incoming,
> >> incoming_channels,
> >> true, true, &local_err);
> >
> > Sure, I can tweak that, but I need to define an additional incoming_uri
> > variable:
> > qmp_migrate_incoming(incoming_uri, !!incoming_channels,
> > incoming_channels, ...
> >
> > Only one of incoming_uri and incoming_channels can be non-NULL (checked in
> > qemu_start_incoming_migration).
> >
> > Would you prefer I continue down this path, or revert to the previous
> > -cpr-uri
> > option? I made this change to make the incoming interface look more like
> > the
> > V4 outgoing interface, in which the user adds a cpr channel to the migrate
> > command
> > channels.
>
> I'm not sure. Peter, what do you think?
For this specific question, I prefer reusing -incoming rather than going
back to -cpr-uri.
We should have discussed about this in the previous spin of a follow up
discussion, using -incoming for cpr channels seems to always be preferred.
https://lore.kernel.org/qemu-devel/Zz4NqcTDK73MKOaa@redhat.com/
At that time, the concern from Dan was not reusing the JSON format or
design the CLI's own format. That was always based on reusing -incoming.
In this patch it's already reusing the JSON for the CPR port, which looks
all good from that POV. OTOH, I don't yet have any preference on the impl
of how QEMU should do the internal parsing of such JSON string / legacy
URIs.
Thanks,
--
Peter Xu
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, (continued)
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, Peter Xu, 2024/12/13
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, Steven Sistare, 2024/12/13
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, Steven Sistare, 2024/12/18
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, Peter Xu, 2024/12/18
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, Steven Sistare, 2024/12/18
- Re: [PATCH V4 06/19] physmem: preserve ram blocks for cpr, Peter Xu, 2024/12/18
[PATCH V4 09/19] migration: incoming channel, Steve Sistare, 2024/12/02
Re: [PATCH V4 09/19] migration: incoming channel, Markus Armbruster, 2024/12/10
[PATCH V4 17/19] tests/migration-test: defer connection, Steve Sistare, 2024/12/02