[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] migration: Don't try and recover return path in non-postcopy
From: |
Peter Xu |
Subject: |
Re: [PATCH] migration: Don't try and recover return path in non-postcopy |
Date: |
Tue, 8 Oct 2019 22:14:42 +0800 |
User-agent: |
Mutt/1.11.4 (2019-03-13) |
On Mon, Oct 07, 2019 at 11:35:07AM +0100, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <address@hidden>
>
> 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 <address@hidden>
> Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> ---
> 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 <address@hidden>
--
Peter Xu