On Tue, May 07, 2013 at 09:58:52AM -0500, sheng qiu wrote: > i am trying to figure out the code path which translate the emulated > disk IO issued by VM to actual physical disk IO on host side. Can > anyone give me a clear view about this? For an overview of the stack: http://events.linuxfoundation.org/slides/2011/linuxcon-japan/lcj2011_hajnoczi.pdf > i read the kvm side code about the VMexit handling, the handle_io() > will be called for IO exits. for IO job that cannot be handled inside > the hyperviser, it will switch to qemu-kvm process and the handle_io() > at qemu side will be called. finally it seems invoke the > ioport_read()/ioport_write() which invoke the actual registered > read/write operator. Then i get lost here, i do not know for emulated > disk io which function will be responsible for the remaining job. i.e. > catch the cmd for accessing the virtual disk and translate to the > read/write to offset of the disk img file (assume we use file for > virtual disk), and then issue the system call to the host to issue the > real io cmd to physical disk. If you are running with a virtio-blk PCI adapter, then QEMU's virtio_queue_host_notifier_read() or virtio_ioport_write() is invoked (it depends whether ioeventfd is being used or regular I/O dispatch). Then QEMU's hw/block/virtio-blk.c will call bdrv_aio_readv()/bdrv_aio_writev()/bdrv_aio_flush(). This enters the QEMU block layer (see block.c and block/) where image file formats are handled. Eventually you get to block/raw-posix.c which issues either a preadv()/pwritev()/fdatasync() in a worker thread or a Linux AIO io_submit() (if -drive aio=native was used). Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
