* Paolo Bonzini ([email protected]) wrote:
> 
> 
> On 13/04/2015 13:35, Dr. David Alan Gilbert wrote:
> >>>>>>> +    qemu_system_wakeup_request(QEMU_WAKEUP_REASON_OTHER);
> >>>>>>> > >>> > > +    *old_vm_running = runstate_is_running();
> >>>>> > >> > 
> >>>>> > >> > I think that needs some explanation.  Why are you doing a wakeup 
> >>>>> > >> > on
> >>>>> > >> > the source host?
> >>> > > This matches the existing code in migration_thread for the end of 
> >>> > > precopy;
> >>> > > Paolo's explanation of what it does is here:
> >>> > > https://lists.gnu.org/archive/html/qemu-devel/2014-08/msg04880.html
> >> > 
> >> > The more I look at it, the more I'm convinced it's working by chance or
> >> > not working at all.
> > Do you mean in general or in the postcopy case?
> 
> In general.

OK, then lets take this off this thread and fix it generally
and just make sure postcopy is consistent with whatever that
change is.

> > > Here we probably need to do only the notifier_list_notify +
> > > qapi_event_send_wakeup.
> >
> > Do you mean a :
> >    wakeup_reason = QEMU_WAKEUP_REASON_OTHER;
> >    notifier_list_notify(&wakeup_notifiers, &wakeup_reason);
> >    wakeup_reason = QEMU_WAKEUP_REASON_NONE;
> >    qapi_event_send_wakeup(&error);
> > 
> > which I guess would need wrapping up in vl.c
> 
> Yes.
> 
> > (It's not really clear to me what this stuff does even with
> > your previous explanation; if it's to do with migrating
> > something suspended-to-ram I guess a postcopy is possible
> > but it doesn't seem that sensible to use postcopy for a
> > machine with a CPU that isn't running).
> 
> Yes, but management does not know in advance that the machine will
> suspend to RAM.  It's basically a race.

OK, reasonable.

Dave

> 
> Paolo
--
Dr. David Alan Gilbert / [email protected] / Manchester, UK

Reply via email to