Re: [Qemu-devel] [Bug?] BQL about live migration

[Yang Hongyang]

Hi Dave,

On Fri, Mar 3, 2017 at 9:26 PM, Dr. David Alan Gilbert <address@hidden>
wrote:

> * Paolo Bonzini (address@hidden) wrote:
> >
> >
> > On 03/03/2017 14:11, Dr. David Alan Gilbert wrote:
> > > * Paolo Bonzini (address@hidden) 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 / address@hidden / Manchester, UK
>
>