Hi Dave, On Fri, Mar 3, 2017 at 9:26 PM, Dr. David Alan Gilbert <dgilb...@redhat.com> wrote:
> * Paolo Bonzini (pbonz...@redhat.com) wrote: > > > > > > On 03/03/2017 14:11, Dr. David Alan Gilbert wrote: > > > * Paolo Bonzini (pbonz...@redhat.com) wrote: > > >> > > >> > > >> On 03/03/2017 13:00, Dr. David Alan Gilbert wrote: > ... > > > That event feature went in sometime after 2.3.0. > > > > > >> One possibility is to suspend the monitor in qmp_migrate_cancel and > > >> resume it (with add_migration_state_change_notifier) when we hit the > > >> CANCELLED state. I'm not sure what the latency would be between the > end > > >> of migrate_fd_cancel and finally reaching CANCELLED. > > > > > > I don't like suspending monitors; it can potentially take quite a > significant > > > time to do a cancel. > > > How about making 'cont' fail if we're in CANCELLING? > > > > Actually I thought that would be the case already (in fact CANCELLING is > > internal only; the outside world sees it as "active" in query-migrate). > > > > Lei, what is the runstate? (That is, why did cont succeed at all)? > > I suspect it's RUN_STATE_FINISH_MIGRATE - we set that before we do the > device > It is RUN_STATE_FINISH_MIGRATE. > save, and that's what we get at the end of a migrate and it's legal to > restart > from there. > > > Paolo > > > > > I'd really love to see the 'run_on_cpu' being more careful about the > BQL; > > > we really need all of the rest of the devices to stay quiesced at > times. > > > > That's not really possible, because of how condition variables work. :( > > *Really* we need to find a solution to that - there's probably lots of > other things that can spring up in that small window other than the > 'cont'. > This is what I was worry about. Not only sync_cpu_state() will call run_on_cpu() but also vm_stop_force_state() will, both of them did hit the small windows in our test. > > Dave > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > >
