[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] Virtio-BLK/SCSI write requests and data payload checksu
From: |
Peter Lieven |
Subject: |
Re: [Qemu-block] Virtio-BLK/SCSI write requests and data payload checksums |
Date: |
Tue, 18 Dec 2018 11:07:13 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 |
Am 18.12.18 um 10:34 schrieb Stefan Hajnoczi:
> On Mon, Dec 17, 2018 at 04:19:53PM +0100, Peter Lieven wrote:
>> Actually I don't know for sure that the address comes from the guest. In
>> theory it could be that
>> the request from the guest was less than 4096 byte and Qemu just assigned a
>> bounce buffer
>> to read the whole block and copied the relevant part to the guest. Can I see
>> from the
>> address (0x7fa4354c0000) if it comes from Qemu or the guest?
> Something like this:
>
> $ awk '/rw-p/ { split($1, a, "-"); print $1, strtonum("0x" a[2]) -
> strtonum("0x" a[1])}' /proc/$(pgrep qemu)/maps
> ...
> 7f01d3e00000-7f0213e00000 1073741824 <-- this must be my 1 GB guest RAM!
> ...
>
> Then you can check if the memory address falls within the guest RAM
> range.
>
> By the way, if you use special memory options (like share=on), then you
> may need to adjust the awk script since the mmap will look different.
I use hugetblfs, but from what I found in maps it seems to be guest memory
(other running vm with a buffer collision at 0x7f52eb6c0000; the original one
has gone).
7f52e7e00000-7f5467e00000 rw-p 00000000 00:32 38983264
/hugepages/qemu_back_mem.pc.ram.7f9SYs (deleted)
Best,
Peter