Re: [Qemu-devel] GSoC: Improved image format compatibility

2011/4/3 Stefan Hajnoczi <address@hidden>

On Sat, Apr 2, 2011 at 8:03 PM, Lyu Mitnick <address@hidden> wrote:
> Hello Stefan,
> I have take a look at block.c. But I am a little confused about the meaning
> of synchronous/asynchronous i/o. I know the two concept in a operating
> system. However I am not sure whether it is analogous in virtual machine.

You may want to read up on the QEMU threading model:
http://blog.vmsplice.net/2011/03/qemu-internals-overall-architecture-and.html

(Over)simplifying a bit, only one host thread can be executing QEMU
code at any given time because QEMU is not thread-safe internally. If
the VM issues a disk read and QEMU uses a read(2) system call to
service it, then QEMU and the VM is blocked until the read(2) system
call completes. Therefore it is better to use asynchronous I/O in
QEMU and resume the VM. Once the read operation completes a callback
in QEMU is invoked and we can signal completion back to the VM.

Also, in terms of the storage controller interfaces that QEMU emulates
(IDE, SCSI, virtio-blk) disk operations are queued or handed to the
hardware. The guest operating system expects to continue executing
while the disk operation is in progress. On completion the storage
controller raises an interrupt and the operating system will complete
the I/O. Again, this is an asynchronous (request/response) model
rather than a synchronous operation from the guest operating system
perspective.

Look at hw/virtio-blk.c:virtio_blk_handle_output() for an example of
how disk emulation works in QEMU.

For qemu-img it is more natural to use synchronous I/O because it is
just a sequential C program, not an event-driven program like QEMU.

Stefan

From:	Lyu Mitnick
Subject:	Re: [Qemu-devel] GSoC: Improved image format compatibility
Date:	Tue, 5 Apr 2011 01:35:34 +0800