[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: |
Vadim Rozenfeld |
Subject: |
Re: [Qemu-block] Virtio-BLK/SCSI write requests and data payload checksums |
Date: |
Fri, 11 Jan 2019 18:14:33 +1100 |
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.
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
>
>
>