Re: [Qemu-devel] [patch 6/7] QEMU live block copy

[Jagane Sundar <jagane@sundar.org>]

>> Hello Stefan,
>>
>> Can you expand on this some more? I have similar concerns for Livebackup.
>>
>> At the beginning of your paragraph,  did you mean 'asynchronous I/O
>> emulation' instead of 'synchronous I/O emulation'?
>>
>> Also, I don't understand the 'stack' construct that you refer to. When you
>> say 'push a new context', are you talking about what happens when a new
>> thread picks up a new async I/O req from the VM, and then proceeds to
>> execute the I/O req? What is this stack that you refer to?
>>
>> Any design documents, code snippets that I can look, other pointers welcome.
> See async.c.
>
Thanks - I will do so.
> There is synchronous I/O emulation in block.c for BlockDrivers that
> don't support .bdrv_read()/.bdrv_write() but only
> .bdrv_aio_readv()/.bdrv_aio_writev().  The way it works is that it
> pushes a new I/O context and then issues async I/O.  Then it runs a
> special event loop waiting for that I/O to complete.  After the I/O
> completes it pops the context again.
>
OK. This is the opposite of what I was thinking of. I was considering
the code that emulates Async I/O using multiple threads.

It sounds like the goal of this async.c mechanism is more than
serializing all synchronous I/O requests, right?
> The point of the context is that completions only get called for the
> current context.  Therefore callers of the synchronous I/O functions
> don't need to worry that the state of the world might change during
> their "synchronous" operation - only their own I/O operation can
> complete.  If a pending async I/O completes during synchronous I/O
> emulation, its callback is not invoked until the bottom half (BH) is
> called after the async context is popped.  This guarantees that the
> synchronous operation and its caller have completed before I/O
> completion callbacks are invoked for pending async I/O.
>
OK. This might not be a problem for Livebackup, after all.
Livebackup transparently interposes the async I/O offered by the driver.
Hence the async.c mechanism is layered neatly above the
async_block_driver+livebackup layer and should work correctly.

I will take a closer look at this, and check for sanity...


Thanks,
Jagane