From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXTMT-00037y-IW for qemu-devel@nongnu.org; Wed, 01 May 2013 05:30:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXTMS-0005Co-HA for qemu-devel@nongnu.org; Wed, 01 May 2013 05:30:05 -0400 Received: from mail-bk0-x229.google.com ([2a00:1450:4008:c01::229]:60229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXTMS-000584-Bd for qemu-devel@nongnu.org; Wed, 01 May 2013 05:30:04 -0400 Received: by mail-bk0-f41.google.com with SMTP id jc3so570863bkc.14 for ; Wed, 01 May 2013 02:30:03 -0700 (PDT) Date: Wed, 1 May 2013 11:30:00 +0200 From: Stefan Hajnoczi Message-ID: <20130501093000.GA21804@stefanha-thinkpad.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] Query regarding IO paths in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: aayush gupta Cc: qemu-devel@nongnu.org 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