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:
>>>>
>>>> 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:

file_write (s->write of fd-migration) returns EAGAIN
migrate_fd_put_buffer calls qemu_set_fd_handler2 with migrate_fd_put_notify
upon the next main_loop_wait fd is found writable and migrate_fd_put_notify is 
called.
qemu_file_put_notify is called.
buffered_put_buffer is called.
buffered_flush is called.
s->freeze_output=0
migrate_fd_put_buffer is called
file_write is called again -- here I can check if previous aio write finished.


>>
>> Your concern in the previous patch was that write() to a regular file 
>> might block. That's why I'm calling select before calling write. Do 
>> you think select will mark the fd as writeable but write would still 
>> block ?
> 
> select() doesn't help.  It will return that the file descriptor is 
> writable and then the subsequent write will block.

Sure looks like a bug.
I'll send my v3 using posix-aio-compat for review soon.

Thanks,
     Uri.