qemu-block
[Top][All Lists]
Advanced

[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
> 
> typedef struct _STOR_SCATTER_GATHER_ELEMENT {
>  STOR_PHYSICAL_ADDRESS PhysicalAddress;
>  ULONG                 Length;
>  ULONG_PTR             Reserved;
> } STOR_SCATTER_GATHER_ELEMENT,
> *PSTOR_SCATTER_GATHER_ELEMENT;
> 
> 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,
Peter

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