Re: [Qemu-devel] migration: adding migration to/from a file (v2)

[Uri Lublin]

Anthony Liguori wrote:
> Uri Lublin wrote:
> > Anthony Liguori wrote:
> > > Uri Lublin wrote:
> > > > Anthony Liguori wrote:
> > > > > Uri Lublin wrote:
> > > > > > Migration to file, uses migration-to-fd (supports live migration).
> > > > > > Migration from file, uses qemu-fopen directly.
> > > > >
> > > > > Eh?  Haven't we already talked about why this doesn't work?  Maybe 
> > > > > there's a v3 that you meant to send?
> > > >
> > > > Actually I do have a v3 which uses posix-aio-compat.c
> > > > It's a much more complicated solution then just writing to a file 
> > > > though.
> > > > Also I am not sure if I need to use a signal or not as the migration 
> > > > (to-fd) code is polling. And if I use signal should I use SIGUSR2 or 
> > > > a different one and use a pipe similar to block-raw-posix.c ?
> > >
> > > How is the migration code polling?  It will attempt to do writes 
> > > until a write returns EAGAIN.  At this point, it will wait for 
> > > notification that the more writes are available.  Remember, migration 
> > > is a streaming protocol, not a random access, so it only makes sense 
> > > to have one outstanding request at a time.
> > >
> > > Your code would look something like:
> > >
> > > write() -> submit aio request
> > > until aio completes, write returns EAGAIN
> > > when aio completes, notify migration code that we are writable again
> >
> > Basically that's what I've done in my v3.
> > But since I fake EAGAIN, and the fd is writeable by select, the 
> > scenario is as follows:
>
> Oh, yes, this is a problem.  You cannot use the existing migrate_fd code 
> unfortunately :-(
>
> Or maybe you can.  If you change all instances of  
> qemu_set_fd_handler2() in migrate.c (in the migrate_fd_ routines) to 
> basically, s->set_fd_handler(), you can introduce a simple wrapper that 
> calls qemu_set_fd_handler2() for everything else, but for yourself, use 
> it as a mechanism to keep track of what the "writable" callback should 
> be.  This is the callback you would invoke when the aio request completes.

So it looks simpler to just (v4 implementation) spawn a single writing thread, 
and use a pipe to "connect" it to the migration code (as the pipe supports 
non-blocking write).

Would that be acceptable, or you prefer I'll implement s->set_fd_handler() ?
In that case will need another thread and pipe for compatfd (qemu_signalfd), and 
allocate a buffer to hold the data until it's written (as the original buffer 
may change).

Thanks,
    Uri.