[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 28/29] migration: final handshake for the resume
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [RFC 28/29] migration: final handshake for the resume |
Date: |
Fri, 4 Aug 2017 10:53:42 +0100 |
User-agent: |
Mutt/1.8.3 (2017-05-23) |
* Peter Xu (address@hidden) wrote:
> On Thu, Aug 03, 2017 at 02:47:44PM +0100, Dr. David Alan Gilbert wrote:
>
> [...]
>
> > > +static int postcopy_resume_handshake(MigrationState *s)
> > > +{
> > > + qemu_mutex_lock(&s->resume_lock);
> > > +
> > > + qemu_savevm_send_postcopy_resume(s->to_dst_file);
> > > +
> > > + while (s->state == MIGRATION_STATUS_POSTCOPY_RECOVER) {
> > > + qemu_cond_wait(&s->resume_cond, &s->resume_lock);
> > > + }
> > > +
> > > + qemu_mutex_unlock(&s->resume_lock);
> > > +
> > > + if (s->state == MIGRATION_STATUS_POSTCOPY_ACTIVE) {
> > > + return 0;
> > > + }
> >
> > That feels to be a small racy - couldn't that validly become a
> > MIGRATION_STATUS_COMPLETED before that check?
>
> Since postcopy_resume_handshake() is called in migration_thread()
> context, so it won't change to complete at this point (confirmed with
> Dave offlist on the question).
Yes.
> >
> > I wonder if we need to change migrate_fd_cancel to be able to
> > cause a cancel in this case?
>
> Yeah that's important, but haven't considered in current series. Do
> you mind to postpone it as TODO as well (along with the work to allow
> the user to manually switch to PAUSED state, as Dan suggested)?
Yes I don't the cancel in that case is that important; it's already in
the recovery from a bad situation.
Dave
> --
> Peter Xu
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK