From: Juan Quintela <quintela@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, "Dr . David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] migration: unbreak postcopy recovery
Date: Wed, 27 Jun 2018 11:57:55 +0200 [thread overview]
Message-ID: <87po0clffg.fsf@secure.laptop> (raw)
In-Reply-To: <20180611060228.2998-2-peterx@redhat.com> (Peter Xu's message of "Mon, 11 Jun 2018 14:02:27 +0800")
Peter Xu <peterx@redhat.com> wrote:
> It was broken due to recent changes in two parts:
>
> - migration_incoming_process() will be called now even for postcopy
> recovery sessions (while we shouldn't)
>
> - Now we don't call migrate_fd_process_incoming() any more (unless in
> RDMA code), so actually the postcopy recovery logic is fully bypassed
>
> Fix this up to make sure we only call migration_incoming_process() when
> necessary, and move the postcopy recovery logic far earlier to the entry
> point of incoming migration. Renaming migration_fd_process_incoming()
> into postcopy_try_recover() since it's mostly for the recovery process,
> then touch up RDMA code to suite it.
>
> Since at it, refactor the imcoming port handling to only have one singe
> entry point for incoming migration. Then we can avoid calling
> migration_ioc_process_incoming() everywhere, which is really error
> prone.
Perhaps splitting some of this bits?
> diff --git a/migration/ram.h b/migration/ram.h
> index d386f4d641..457bf54b8c 100644
> --- a/migration/ram.h
> +++ b/migration/ram.h
> @@ -46,7 +46,7 @@ int multifd_save_cleanup(Error **errp);
> int multifd_load_setup(void);
> int multifd_load_cleanup(Error **errp);
> bool multifd_recv_all_channels_created(void);
> -void multifd_recv_new_channel(QIOChannel *ioc);
> +bool multifd_recv_new_channel(QIOChannel *ioc);
I am ok with this type change.
> void migration_ioc_process_incoming(QIOChannel *ioc)
> {
> MigrationIncomingState *mis = migration_incoming_get_current();
> + QEMUFile *f = qemu_fopen_channel_input(ioc);
We are creating a QEMUFile here.
> + bool start_migration;
> +
> + /* If it's a recovery attempt, we're done */
> + if (postcopy_try_recover(f)) {
Here we use it.
> + return;
> + }
>
> if (!mis->from_src_file) {
> - QEMUFile *f = qemu_fopen_channel_input(ioc);
> + /* The first connection (multifd may have multiple) */
> migration_incoming_setup(f);
Here we use it.
> - return;
> + /*
> + * Common migration only needs one channel, so we can start
> + * right now. Multifd needs more than one channel, we wait.
> + */
> + start_migration = !migrate_use_multifd();
> + } else {
> + /* Multiple connections */
> + assert(migrate_use_multifd());
> + start_migration = multifd_recv_new_channel(ioc);
But here we don't use it. We are lecking it.
So, we need to fix the leak. No clue about how to convince
postcopy_try_recover() without the QEMUFile
Later, Juan.
next prev parent reply other threads:[~2018-06-27 9:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-11 6:02 [Qemu-devel] [PATCH 0/2] migation: unbreak postcopy recovery Peter Xu
2018-06-11 6:02 ` [Qemu-devel] [PATCH 1/2] migration: " Peter Xu
2018-06-27 9:57 ` Juan Quintela [this message]
2018-06-27 10:23 ` Peter Xu
2018-06-11 6:02 ` [Qemu-devel] [PATCH 2/2] migration: delay postcopy paused state Peter Xu
2018-06-27 9:11 ` Juan Quintela
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=87po0clffg.fsf@secure.laptop \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.