From: Juan Quintela <quintela@redhat.com>
To: Laurent Vivier <lvivier@redhat.com>
Cc: Jens Freimann <jfreimann@redhat.com>,
qemu-devel@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 2/2] migration: failover: continue to wait card unplug on error
Date: Wed, 30 Jun 2021 11:13:55 +0200 [thread overview]
Message-ID: <871r8jzpd8.fsf@secure.mitica> (raw)
In-Reply-To: <c7ec3af8-5649-4e53-ef5c-39f7adc54e2b@redhat.com> (Laurent Vivier's message of "Wed, 30 Jun 2021 11:04:38 +0200")
Laurent Vivier <lvivier@redhat.com> wrote:
> On 29/06/2021 19:50, Juan Quintela wrote:
>> Laurent Vivier <lvivier@redhat.com> wrote:
>>> If the user cancels the migration in the unplug-wait state,
>>> QEMU will try to plug back the card and this fails because the card
>>> is partially unplugged.
>>> To avoid the problem, continue to wait the card unplug, but to
>>> allow the migration to be canceled if the card never finishes to unplug
>>> use a timeout.
>>>
>>> Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1976852
>>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>>> ---
>>> migration/migration.c | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/migration/migration.c b/migration/migration.c
>>> index 3e92c405a2b6..3b06d43a7f42 100644
>>> --- a/migration/migration.c
>>> +++ b/migration/migration.c
>>> @@ -3679,6 +3679,17 @@ static void qemu_savevm_wait_unplug(MigrationState *s, int old_state,
>>> qemu_savevm_state_guest_unplug_pending()) {
>>> qemu_sem_timedwait(&s->wait_unplug_sem, 250);
>>> }
>>> + if (s->state != MIGRATION_STATUS_WAIT_UNPLUG) {
>>> + int timeout = 120; /* 30 seconds */
>>> + /*
>>> + * migration has been canceled
>>> + * but as we have started an unplug we must wait the end
>>> + * to be able to plug back the card
>>> + */
>>> + while (timeout-- && qemu_savevm_state_guest_unplug_pending()) {
>>> + qemu_sem_timedwait(&s->wait_unplug_sem, 250);
>>> + }
>>> + }
>>>
>>> migrate_set_state(&s->state, MIGRATION_STATUS_WAIT_UNPLUG, new_state);
>>> } else {
>> I agree with the idea. But if we are getting out due to timeout == 0,
>> shouldn't we return some error, warning, whatever?
>
> In that case, we keep the current behaviour: guest kernel will report
> an error when it
> will try to plug back the card that has not been unplugged. This is a
> corner case: if it
> happens we have something really wrong with the machine. Perhaps we can remove the
> timeout, but I don't like to block the user, or increase it to be sure.
Oh, I whole agree that it is a corner case, and that it shouldn't
happen.
But if it happens, we don't log it anywhere. That was my complaint.
Later, Juan.
next prev parent reply other threads:[~2021-06-30 9:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-29 15:50 [PATCH 0/2] migration: failover: continue to wait card unplug on error Laurent Vivier
2021-06-29 15:50 ` [PATCH 1/2] migration: move wait-unplug loop to its own function Laurent Vivier
2021-06-29 17:30 ` Dr. David Alan Gilbert
2021-06-29 17:47 ` Juan Quintela
2021-06-29 17:48 ` Dr. David Alan Gilbert
2021-06-29 15:50 ` [PATCH 2/2] migration: failover: continue to wait card unplug on error Laurent Vivier
2021-06-29 17:50 ` Juan Quintela
2021-06-30 9:04 ` Laurent Vivier
2021-06-30 9:13 ` Juan Quintela [this message]
2021-06-30 17:48 ` Dr. David Alan Gilbert
2021-06-30 17:54 ` [PATCH 0/2] " Dr. David Alan Gilbert
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=871r8jzpd8.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=dgilbert@redhat.com \
--cc=jfreimann@redhat.com \
--cc=lvivier@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.