qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] Disk Image Read Location
@ 2017-09-18 18:47 Derrick McKee
  2017-09-18 19:26 ` Max Reitz
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Derrick McKee @ 2017-09-18 18:47 UTC (permalink / raw)
  To: qemu-devel@nongnu.org

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.

- Derrick McKee
-- 
Derrick McKee
Ph.D. Student at Purdue University

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] Disk Image Read Location
  2017-09-18 18:47 [Qemu-devel] Disk Image Read Location Derrick McKee
@ 2017-09-18 19:26 ` Max Reitz
  2017-09-19  0:43 ` John Snow
  2017-09-19  9:23 ` Stefan Hajnoczi
  2 siblings, 0 replies; 4+ messages in thread
From: Max Reitz @ 2017-09-18 19:26 UTC (permalink / raw)
  To: Derrick McKee, qemu-devel@nongnu.org, Qemu-block

[-- 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 --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] Disk Image Read Location
  2017-09-18 18:47 [Qemu-devel] Disk Image Read Location Derrick McKee
  2017-09-18 19:26 ` Max Reitz
@ 2017-09-19  0:43 ` John Snow
  2017-09-19  9:23 ` Stefan Hajnoczi
  2 siblings, 0 replies; 4+ messages in thread
From: John Snow @ 2017-09-19  0:43 UTC (permalink / raw)
  To: Derrick McKee, qemu-devel@nongnu.org



On 09/18/2017 02:47 PM, Derrick McKee wrote:
> Hi,
> 

Hi Derrick;

> 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

Which device handles the USB disk emulation? hw/usb/dev-storage.c?
("usb-storage")?

> 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.
> 
> - Derrick McKee
>

address_space_write is merely the function that is handling guest writes
to memory, not guest writes to disk.

Likely, your guest is writing some kind of disk IO command to whatever
sort of disk controller you have, and this process is dispatched by a
write to a register somewhere. If you wanted to snoop the disk activity
at this high of a level, you'd have to understand the protocol the
hardware uses to perform IO, look at the value being written to the
HWAddr, and re-interpret the state of the device and so on to see what
data is being read/written. The addresses you see here are likely just
registers that belong to the disk controller, so they don't reflect disk
offsets.

What I'd suggest instead is that you take a look at the dispatch for
address_space_write and follow it to the handler for the device emulator
that is actually handling the write and trace through the device
emulator code to find where the actual reading/writing is taking place.
The disk emulation code being employed is likely a good and logical
place to enable tracing of particular offsets at the logical level.

If you want to know about reads/writes at a more concrete level after
translation for offsets for file formats and so on and so forth -- if
you were curious to know how many literal, actual read calls get issued
-- keep looking down the stack.

>From the device emulator, calls to QEMU's generic block layer are made.
Usually blk_aio_preadv or dma_blk_read, something along these lines.
Ultimately, if you're reading from qcow2 or raw files on a locally
mounted hard disk, you'll probably trace the modular block layer read
calls all the way down to raw_co_preadv, then to raw_co_prw, then to
either laio_co_submit (if linux_aio is enabled) or paio_submit_co if it
isn't.

Then maybe you'll trace, say, paio_submit_co down (eventually) to the
constituent pwrite/pread calls.

Hard to know exactly what you want. Tracking guest IO activity and
tracking QEMU IO activity become slightly different things due to cache,
alignment and other protocol/format translations QEMU might be
performing. Hopefully this sets you on the right path. Other folks will
correct me if I've taken too many liberties at distilling all the stuff
going on inside of QEMU. ;)

Hope this helps,
John.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Qemu-devel] Disk Image Read Location
  2017-09-18 18:47 [Qemu-devel] Disk Image Read Location Derrick McKee
  2017-09-18 19:26 ` Max Reitz
  2017-09-19  0:43 ` John Snow
@ 2017-09-19  9:23 ` Stefan Hajnoczi
  2 siblings, 0 replies; 4+ messages in thread
From: Stefan Hajnoczi @ 2017-09-19  9:23 UTC (permalink / raw)
  To: Derrick McKee; +Cc: qemu-devel@nongnu.org

On Mon, Sep 18, 2017 at 06:47:38PM +0000, Derrick McKee wrote:
> I am trying to figure out if a particular disk operation is reading from
> the same location in an image file.

The following trace event is fired when a BlockBackend (a drive) is
read:

  # block/block-backend.c
  blk_co_preadv(void *blk, void *bs, int64_t offset, unsigned int bytes, int flags) "blk %p bs %p offset %"PRId64" bytes %u flags 0x%x"

Here is an example:

  $ qemu-system-x86_64 -M accel=kvm -m 1G -cpu host \
                       -trace enable=blk_co_preadv \
		       -drive if=virtio,file=test.img,format=raw
23087@1505812623.056729:blk_co_preadv blk 0x55f703389390 bs 0x55f7033895f0 offset 0 bytes 512 flags 0x0
23087@1505812623.176042:blk_co_preadv blk 0x55f703389390 bs 0x55f7033895f0 offset 0 bytes 512 flags 0x0

"offset" is the byte address that the guest is reading from.

See docs/devel/tracing.txt for more information on tracing.  One or more
tracing backends are compiled into QEMU.  By default the "log" backend
prints to stderr.

If you are using the QEMU binary from a Linux distribution package, they
may have compiled in only the SystemTap backend so try compiling your
own QEMU if you don't see any output from the example above.

Stefan

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-09-19  9:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-18 18:47 [Qemu-devel] Disk Image Read Location Derrick McKee
2017-09-18 19:26 ` Max Reitz
2017-09-19  0:43 ` John Snow
2017-09-19  9:23 ` Stefan Hajnoczi

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).