[Qemu-devel] Query regarding IO paths in QEMU

[Qemu-devel] Query regarding IO paths in QEMU

[aayush gupta]

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

Hi,

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

qcow2_co_readv() -> bdrv_co_readv() [back into block.c] ->
bdrv_co_do_readv()

After this it looks like the driver specific function is called again. I am
pretty sure I am missing something here or my understanding is incorrect.

Can you please help me in understanding the complete IO path from the guest
VM into QEMU and from QEMU into the host? What are some of the other things
I should be careful about.

I am a complete novice in QEMU/KVM environment and would really appreciate
any help you can provide.

Thanks in advance,
Aayush

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

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

[Stefan Hajnoczi]

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

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

[aayush gupta]

[-- 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 --]

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

[Stefan Hajnoczi]

On Mon, May 06, 2013 at 02:36:46PM -0700, aayush gupta wrote:
> 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.

Invoke simpletrace.py like this:

  $ scripts/simpletrace.py trace-events <trace-file>

If tracing doesn't work with qemu-iotests, try it manually first:

  $ qemu-io -T /tmp/events -c 'read 0 512' test.img

Stefan