From: Shailesh Kumar <tsaileshkumar@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [Qemu-devel] [Block dev] : Qemu block ide_dma_read call routine
Date: Thu, 23 Jul 2015 12:20:30 -0700 [thread overview]
Message-ID: <CACY1rB71Y+t4Lm9OtjNog+ZeKughw_Owv_A9fu9KM69rh2ZzBQ__9214.87906384773$1437679313$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <20150223112557.GC4302@noname.str.redhat.com>
On Mon, Feb 23, 2015 at 3:25 AM, Kevin Wolf <kwolf@redhat.com> 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
next prev parent reply other threads:[~2015-07-23 19:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 3:51 [Block dev] : Qemu block ide_dma_read call routine Shailesh Kumar
2015-02-23 11:25 ` [Qemu-devel] " Kevin Wolf
[not found] ` <20150223112557.GC4302@noname.str.redhat.com>
2015-07-23 19:20 ` Shailesh Kumar [this message]
[not found] ` <CACY1rB71Y+t4Lm9OtjNog+ZeKughw_Owv_A9fu9KM69rh2ZzBQ@mail.gmail.com>
2015-07-24 10:58 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACY1rB71Y+t4Lm9OtjNog+ZeKughw_Owv_A9fu9KM69rh2ZzBQ__9214.87906384773$1437679313$gmane$org@mail.gmail.com' \
--to=tsaileshkumar@gmail.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).