From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shailesh Kumar Subject: Re: [Qemu-devel] [Block dev] : Qemu block ide_dma_read call routine Date: Thu, 23 Jul 2015 12:20:30 -0700 Message-ID: References: <20150223112557.GC4302@noname.str.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150223112557.GC4302@noname.str.redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Kevin Wolf Cc: qemu-devel@nongnu.org, "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Mon, Feb 23, 2015 at 3:25 AM, Kevin Wolf wrote: > Am 11.02.2015 um 04:51 hat Shailesh Kumar geschrieben: >> Hi, >> >> I am implementing read equivalent routine in qemu. Can some one >> help me understand control flow of the qemu read/write >> implementation. >> >> I am using xen-4.2.0 and qemu-1.6.1 >> >> My requirement is simple: >> >> I have a 1024*1024 buffer already filled with some useful data. >> >> Now when windows (my guest OS) does IDE_DMA_READ command to the disk, >> I want to intercept it and fill data from my private buffer. >> >> my intention is to leverage existing dma_read infrastructure and >> overwrite the read buffer-data at the lowest level of qemu . That way >> the buffers /vectors "qiov" which are prepared due to cmd IDE_DMA_READ >> will copy and return data from my data-buffer to guest-OS. >> >> I could trace the control from. >> >> ide_sector_start_dma >> -> s->bus->dma->ops->start_dma >> -> ide_dma_cb >> ->dma_bdrv_read >> -> bdrv_aio_readv >> . ->bdrv_co_aio_rw_vector >> -> bdrv_co_do_rw "coroutine" >> -> bdrv_co_do_readv >> -> drv->bdrv_co_readv (( in my case it is >> from raw.c raw_co_readv )) >> -> bdrv_co_readv > > You need to be aware that BlockDriverStates are actually stacked. In > most common cases you have one protocol driver that accesses the image > file (this might be file, nbd, gluster, http, ssh, etc.) and on top of > that a driver that interprets the image format (like raw, qcow2, vmdk, > etc.) > > You stopped your call chain at the point where the request has passed > through the 'raw' format driver. This final bdrv_co_readv() calls into > drv->bdrv_co_readv of the 'file' driver in raw-posix.c, which is doing > the actual syscalls. > >> -> bdrv_co_do_readv >> >> ->in bdrv_co_do_rw the bottom half is scheduled >> bdrv_co_em_bh -->> this will invoke -> ide_dma_cb () which is >> again the starting point. Looks like there a double-linked list >> maintained for the coroutine entries and are off loaded to qemu-wait >> queue during this process. >> >> Now I need help to understand where to look for to find the last >> read/write system call which will get the data out from the disk for >> guest-OS (windows) . >> >> I am seeking suggestions and help for the same. > > As it might already have occurred to you reading the above, the stacking > provides you a clean way to implement your interception. You just need to > insert a filtering BlockDriver in the chain, so that you end up with: > > raw -> intercept -> file > > You could have a look at the quorum or blkdebug drivers, which can be > inserted in the same way. In contrast to those two drivers, I'd > recommend you to implement bdrv_co_readv/writev instead of > bdrv_aio_readv/writev, because they are probably simpler to use for your > case. > > Kevin Kevin, Thanks for the detailed explanation. Your email gave me little more insight about the control flow. Gmail has put this email at different place and I was not able to find it till now. hence delayed reply. I am confused with format_names. What does host_device mean and what does raw means ? drv->format_name does it mean what form of the driver to be used ? what attributes decide which driver to be used. for e.g: if I print the drv->format_name in bdrv_co_readv I see raw and host_device being printed alternately. -Sailesh