Re: [Qemu-devel] [PATCH 07/46] Return path: Open a return path on QEMUFile for sockets

[Paolo Bonzini <pbonzini@redhat.com>]

Il 16/07/2014 19:10, Dr. David Alan Gilbert ha scritto:
>>> > >
>>> > >Handling it within the migration thread would make it much more complicated
>>> > >(which would be bad since it's already complex enough);
>> >
>> > Ok.  I'm not sure why it is more complicated since migration is essentially
>> > two-phase, one where the source drives it and one where the source just
>> > waits for requests, but I'll trust you on this. :)
> It's not as clean a split like that; during the postcopy phase we still do the linear
> page scan to send pages before they're requested, so the main migration thread
> code keeps going.

Ah, right.  As I said, I trusted you! ;)

>>>>> > >>>    Return path  - opened by main thread, written by main thread AND postcopy
>>>>> > >>>                   thread (protected by rp_mutex)
>>>> > >>
>>>> > >>When does the main thread needs to write?
>>> > >
>>> > >Not much; the only things the main thread currently responds to are the
>>> > >ReqAck (ping like) requests; those are turning out to be very useful during debug;
>>> > >I've also got the ability for the destination to send a migration result back to the
>>> > >source which seems useful to be able to 'fail' early.
>> >
>> > Why can't this be done in the listener thread?  (Thus transforming it into a
>> > more general postcopy migration thread; later we could even change incoming
>> > migration from a coroutine to a thread).
> It depends when the ReqAck is sent; i.e. if it's received when the listener
> thread is running and processing the stream then it's the listener thread that
> sends the reply.

Could the start of the listener thread basically coincide with a 
handover from the main thread to the listener thread?  If so, perhaps 
you can avoid sending ReqAcks packets before the "start destination" 
command (which I suppose should move processing of incoming page data 
from the main thread to the userfaultfd thread).  Then the "start 
destination" command can also change the socket back to blocking.

Paolo

> However, that's not necessarily a big issue now that you've pointed out that
> the destination fd is already running non-blocking.   If the worst comes to the
> worst I could just disable the ReqAck's in non-debug.
>