migration/multifd: Move multifd_send_setup into migration thread
authorFabiano Rosas <farosas@suse.de>
Tue, 6 Feb 2024 21:51:16 +0000 (18:51 -0300)
committerPeter Xu <peterx@redhat.com>
Wed, 7 Feb 2024 01:53:18 +0000 (09:53 +0800)
commitdd904bc13f2af0c605c3fe72f118ea4e27a6610c
tree14e9fe4694ba3a6a8c6fe3e3b811f350549c42c4
parentbd8b0a8f82d8fc17aa285ab963ba75675c2fbe7a
migration/multifd: Move multifd_send_setup into migration thread

We currently have an unfavorable situation around multifd channels
creation and the migration thread execution.

We create the multifd channels with qio_channel_socket_connect_async
-> qio_task_run_in_thread, but only connect them at the
multifd_new_send_channel_async callback, called from
qio_task_complete, which is registered as a glib event.

So at multifd_send_setup() we create the channels, but they will only
be actually usable after the whole multifd_send_setup() calling stack
returns back to the main loop. Which means that the migration thread
is already up and running without any possibility for the multifd
channels to be ready on time.

We currently rely on the channels-ready semaphore blocking
multifd_send_sync_main() until channels start to come up and release
it. However there have been bugs recently found when a channel's
creation fails and multifd_send_cleanup() is allowed to run while
other channels are still being created.

Let's start to organize this situation by moving the
multifd_send_setup() call into the migration thread. That way we
unblock the main-loop to dispatch the completion callbacks and
actually have a chance of getting the multifd channels ready for when
the migration thread needs them.

The next patches will deal with the synchronization aspects.

Note that this takes multifd_send_setup() out of the BQL.

Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Link: https://lore.kernel.org/r/20240206215118.6171-5-farosas@suse.de
Signed-off-by: Peter Xu <peterx@redhat.com>
migration/migration.c