On Mon, Nov 03, 2014 at 07:04:48PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (david@gibson.dropbear.id.au) wrote:
> > On Fri, Oct 03, 2014 at 06:47:16PM +0100, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > 
> > > Postcopy needs a method to send messages from the destination back to
> > > the source, this is the 'return path'.
> > > 
> > > Wire it up for 'socket' QEMUFile's using a dup'd fd.
> > 
> > This doesn't seem like the right abstraction to me.  In particular I
> > can't really see how you'd implement this for anything other than
> > socket.
> > 
> > I'd suggest instead creating new "open" helper functions (within the
> > QEMUFile code) that open both a forward and return path
> > simultaneously.
> 
> Can you give an example of a transport where it would be a problem,
> so I can look at how that works?

pipe

socket routed through some external transport / encoding layer that's
one way only.

> It's a little tricky since, on the destination, at the time we create
> the connection we don't know that we're going to need the return path.

Creating it and not using it shouldn't be a problem though, should it?
As long as you just fall back to precopy rather than failing the
migration if you're unable to open it.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson