From: Max Reitz <mreitz@redhat.com>
To: Derrick McKee <derrick.mckee@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] Disk Image Read Location
Date: Mon, 18 Sep 2017 21:26:25 +0200 [thread overview]
Message-ID: <1ff0af0b-cbcf-7184-3542-ccce908b130e@redhat.com> (raw)
In-Reply-To: <CAJoBWHyqyFiFi_feH=316fJRUbb9T8b4bbYzp-5eUF6dHtpNCg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
On 2017-09-18 20:47, Derrick McKee wrote:
> Hi,
>
> I am trying to figure out if a particular disk operation is reading from
> the same location in an image file. I am simulating a USB disk, and during
> an operation the guest OS performs, I would like to know how many times the
> backing image file is read. I have identified the function
> address_space_write as the function that writes the data to the guest OS
> from the image, but I am not sure what to compare with past writes. There
> are AddressSpace*, MemoryRegion*, and hwaddr types in that function. Can
> any of those be used to compare image read locations? I am hoping that if,
> for example, the AddressSpace* passed into address_space_write during one
> invocation equals the AddressSpace* of another invocation means that the
> same location within the image file was read twice. Any help would be
> appreciated.
If you're referring to images as in images of block devices, then the
block layer contains the functionality you're looking for.
bdrv_driver_preadv() from block/io.c is a function that every read
request should go through. However, at this point it's already aligned
to (host) sectors, so maybe bdrv_co_preadv() is better suited.
But then again, because of how the block layer works you'll likely see
every read request twice there (once for the disk image's format (e.g.
qcow2 or raw) and once for the storage backend used for the image (e.g.
file for normal files or http)). So you either correct for that or you
instead go one layer above into block/block-backend.c.
All read requests from the guest go through either blk_co_preadv() or
blk_aio_preadv(), and they should go through there only once.
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]
next prev parent reply other threads:[~2017-09-18 19:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 18:47 [Qemu-devel] Disk Image Read Location Derrick McKee
2017-09-18 19:26 ` Max Reitz [this message]
2017-09-19 0:43 ` John Snow
2017-09-19 9:23 ` Stefan Hajnoczi
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=1ff0af0b-cbcf-7184-3542-ccce908b130e@redhat.com \
--to=mreitz@redhat.com \
--cc=derrick.mckee@gmail.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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).