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

[aayush gupta]

Thanks for the reply. I am trying to use the tracing with qemu-io as suggested in docs/tracing.txt. I did the following steps:

1. Configure and make with simple backend

2. Create a set of events I am interested in (/tmp/events)

3. Now I am running the qemu-iotests by adding T= /tmp/events to  test 001 testcase (file read path only). 

It runs and generates a trace-xxxxx file. However, the file just has a couple of lines in it in binary.

4. When I pass it through simpletrace.py nothing happens.

Can you tell me if I missed some step or something else needs to be done.

Thanks for your help.

Aayush

On Wed, May 1, 2013 at 2:30 AM, Stefan Hajnoczi <address@hidden> wrote:

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