Hello Peter, On Thu, Nov 24, 2022 at 1:04 PM Peter Xu <[email protected]> wrote: > > On Wed, Nov 09, 2022 at 02:56:29AM -0300, Leonardo Bras wrote: > > diff --git a/migration/savevm.c b/migration/savevm.c > > index a0cdb714f7..250caff7f4 100644 > > --- a/migration/savevm.c > > +++ b/migration/savevm.c > > @@ -1889,6 +1889,8 @@ static void *postcopy_ram_listen_thread(void *opaque) > > exit(EXIT_FAILURE); > > } > > > > + migration_load_cleanup(); > > It's a bit weird to call multifd-load-clean in a listen phase..
I agree. > > How about moving it right above > trace_process_incoming_migration_co_postcopy_end_main()? Then the new > helper can also be static. Seems a nice Idea to have this function to be static. We have to guarantee this is run after the migration finished, but before migration_incoming_state_destroy(). You suggested calling it right above of trace_process_incoming_migration_co_postcopy_end_main(), which git grep pointed me to an if clause in process_incoming_migration_co(). If I got the location correctly, it would not help: this coroutine is ran just after the VM went to the target host, and not when the migration finished. If we are using multifd channels, this will break the migration with segmentation fault (SIGSEGV), since the channels have not finished sending yet. Best regards, Leo > > > + > > migrate_set_state(&mis->state, MIGRATION_STATUS_POSTCOPY_ACTIVE, > > MIGRATION_STATUS_COMPLETED); > > /* > > -- > > 2.38.1 > > > > -- > Peter Xu >
