On Mon, Oct 07, 2019 at 11:35:07AM +0100, Dr. David Alan Gilbert (git) wrote: > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > In normal precopy we can't do reconnection recovery - but we also > don't need to, since you can just rerun migration. > At the moment if the 'return-path' capability is on, we use > the return path in precopy to give a postiive 'OK' to the end > of migration; however if migration fails then we fall into > the postcopy recovery path and hang. This fixes it by only > running the return path in the postcopy case. > > Reported-by: Greg Kurz <gr...@kaod.org> > Signed-off-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > --- > migration/migration.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/migration/migration.c b/migration/migration.c > index 5f7e4d15e9..d5d9b31bb7 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -2481,7 +2481,7 @@ retry: > out: > res = qemu_file_get_error(rp); > if (res) { > - if (res == -EIO) { > + if (res == -EIO && migration_in_postcopy()) {
Makes sense! I saw that in qemu_loadvm_state_main() we're using (postcopy_state_get() == POSTCOPY_INCOMING_RUNNING) to check. That also makes sense because I think we can't really do the recover if the migration stream failed at status like POSTCOPY_INCOMING_DISCARD even if it switched to POSTCOPY_ACTIVE... However that should really be a very corner case even if it's true, and afaict it's nowhere worse... Reviewed-by: Peter Xu <pet...@redhat.com> -- Peter Xu