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