On Fri, Dec 01, 2017 at 12:34:32PM +0000, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > Switch the state until we try to start the VM on destination side. The > > problem is that without doing this we may have a very small window that > > we'll be in such a state: > > > > - dst VM is in postcopy-active state, > > - main thread is handling MIG_CMD_PACKAGED message, which loads all the > > device states, > > - ram load thread is reading memory data from source. > > > > Then if we failed at this point when reading the migration stream we'll > > also switch to postcopy-paused state, but that is not what we want. If > > device states failed to load, we should fail the migration directly > > instead of pause. > > > > Postponing the state switch to the point when we have already loaded the > > devices' states and been ready to start running destination VM. > > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > If it's the only way, then this is OK; but I'd prefer you use a separate > flag somewhere to let you know this, because this means that > POSTCOPY_ACTIVE on the destination happens at a different point that it > does on the source (and changing it on the source I think will break > lots of things).
Yes, I thought it was fine to postpone it a bit to the point even after receiving the packed data, but I fully understand your point. > Can't you use the PostcopyState value and check if it's in > POSTCOPY_INCOMING_RUNNING? I think, yes. :) Let me drop this patch, instead I'll check explicitly on POSTCOPY_INCOMING_RUNNING state in patch 6. Thanks, -- Peter Xu