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

[Paolo Bonzini]

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.