Re: [Qemu-devel] Query regarding IO paths in QEMU

[Stefan Hajnoczi <stefanha@gmail.com>]

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