[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Query regarding IO paths in QEMU
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] Query regarding IO paths in QEMU |
Date: |
Wed, 1 May 2013 11:30:00 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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,
Stefan Hajnoczi <=