[Top][All Lists]

[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: Mon, 17 Dec 2018 16:19:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

Am 17.12.18 um 15:48 schrieb Stefan Hajnoczi:
On Sun, Dec 16, 2018 at 06:53:44PM +0100, Peter Lieven wrote:
It turned out that for writes a bounce buffer is indeed always necessary. But 
what I found out is that
it seems that even for reads it happens that the OS (Windows in this case) 
issues 2 read requests with
the same buffer in parallel. Is it possible that this is a bug in the virtio or 
has anybone ever seen this before?
Is it Windows resume-from-sleep?  I remember a race condition that
Microsoft fixed.

Its a running guest, no resume. From the dumped Data it seems that its often 
(not always) log files.

The other weird thing I've seen is scatter-gather lists where the same
buffer address is used multiple times within one request (this can go
wrong if the host splits up the request, causing races).

The requests go to different LBAs often several 100MB apart from each other. 
The only thing I

can see it that the request size always seems to be 4096 byte.

I have not seen data corruption so far, but this at all seems very strange.

I only have observed this because the data digest checksum is wrong. After a 
retry it is correct.

When dumping the buffer addresses (in this case the address from the first 
buffer in the qiov)

that came from Qemu/the guest the address is the same.

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]