[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
pgpFbCMkQRv3z.pgp
Description: PGP signature