[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: Fri, 11 Jan 2019 09:50:27 +0100

> Am 11.01.2019 um 08:14 schrieb Vadim Rozenfeld <address@hidden>:
>> On Thu, 2019-01-10 at 14:57 +0100, Peter Lieven wrote:
>>> Am 18.12.18 um 15:45 schrieb Peter Lieven:
>>>> Am 18.12.18 um 14:15 schrieb Vadim Rozenfeld:
>>>> Peter, I must be missing something here, but what exactly the
>>>> problem
>>>> is?
>>> The issue is that I see concurrent read requests coming in from
>>> Windows Guest with vioscsi as driver that
>>> have the same buffer address from guest memory space. I noticed
>>> this because I have Data Digests enabled
>>> and the calculated Digest has a wrong CRC32C. This happens because
>>> the CRC is calculated while or after data
>>> from a second requests reads into the same buffer. I see this only
>>> with Windows and the request size seems
>>> to be always 4K. This is either a bug in Windows, vioscsi or a mad
>>> application issuing concurrent reads using
> vioscsi driver (just like viostor) doesn't allocate any memory by
> itself, except for some small pieces, needed to build virtio queues and
> to maintain some internally used data. 
> All SCSI Request Block (SRB) memory related jobs are done with
> StorPortGetScatterGatherList function which just retrieves SG List from
> the specified SRB. SG List is a set SG Elements, where each elements
> is
>  ULONG                 Length;
>  ULONG_PTR             Reserved;
> PhysicalAddress is a physical address of one single page in a data
> buffer,
> Length is almost always 4K (page size). Theoretically it can be less
> for the first chunk if data buffer is not page aligned, or for the last
> chunk, if buffer size is not rounded up to the page granularity. 
> In my understanding, class driver can allocate SG list from non-paged
> pool, which can explain why you are observing the same memory address
> for different read/write SRBs, just because class driver can recycle
> the same pages from the same non-paged pool.

Vadim, thanks for the explaination. The issue is that I see the same buffer 
address in parallel requests. But if I unterstand you correctly this is likely 
a windows or application issue,


> Best regards,
> Vadim.
>>> the same buffer. From what I have seen in the dumps of the data
>>> that has been read it seems not to be one
>>> common application.
>> Has any of the Windows Developers an idea?
>> Thanks,
>> Peter

reply via email to

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