[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 30/45] Postcopy: Postcopy startup in migratio
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v5 30/45] Postcopy: Postcopy startup in migration thread |
Date: |
Mon, 13 Apr 2015 15:26:20 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 |
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.
> > 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.
Paolo