On Mon, Apr 29, 2013 at 10:02:34AM -0700, aayush gupta wrote: > I am trying to understand the IO paths in QEMU (which I understand emulates > IO for KVM) to have a better idea of how it works and get a clear picture > of how I can trap all read/write requests being issued by the VM in the > QEMU block layer for a project that I am working on. > > For example, lets say that we use QCOW2 image format for VMs. Looking into > the code, I was able to track the requests as follows: > > bdrv_read() -> bdrv_rw_co() -> bdrv_rw_co_entry() -> bdrv_co_do_readv() -> > this calls into driver specific functions
Emulated devices typically use bdrv_aio_readv() instead of the synchronous bdrv_read() function. bdrv_read() would block the guest until the disk operation completes. The model is: Storage controllers (IDE, SCSI, virtio, etc) are emulated by QEMU in hw/. The storage controller has a pointer to a BlockDriverState, which is the block device. BlockDriverStates can form a tree. For example, a qcow2 file actually involves a raw file BlockDriverState and the qcow2 format BlockDriverState. The storage controller has a pointer to the qcow2 format BlockDriverState. The qcow2 code invokes I/O operations on its bs->file field, which will be the raw file BlockDriverState. This abstraction makes it possible to use qcow2 on top of a Sheepdog volume, for example. Also, take a look at docs/tracing.txt. There are pre-defined trace events for block I/O operations. This may be enough to instrument what you need. Stefan
