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

[aayush gupta <aayushgupta.84@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

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 <stefanha@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 3002 bytes --]