qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 10/47] Return path: Open a return path on QEM


From: David Gibson
Subject: Re: [Qemu-devel] [PATCH v4 10/47] Return path: Open a return path on QEMUFile for sockets
Date: Tue, 18 Nov 2014 15:34:52 +1100
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Nov 03, 2014 at 07:04:48PM +0000, Dr. David Alan Gilbert wrote:
> * David Gibson (address@hidden) wrote:
> > On Fri, Oct 03, 2014 at 06:47:16PM +0100, Dr. David Alan Gilbert (git) 
> > wrote:
> > > From: "Dr. David Alan Gilbert" <address@hidden>
> > > 
> > > 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

Attachment: pgpFbCMkQRv3z.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]