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

[Uri Lublin <uril@redhat.com>]

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.