[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: |
Wed, 7 Jun 2017 10:28:46 +0200 |
> Am 07.06.2017 um 01:17 schrieb Paolo Bonzini <address@hidden>:
>
>
>
> ----- Original Message -----
>> From: "Peter Lieven" <address@hidden>
>> To: "qemu block" <address@hidden>
>> Cc: "Paolo Bonzini" <address@hidden>, address@hidden, address@hidden, "Max
>> Reitz" <address@hidden>,
>> "Michael S. Tsirkin" <address@hidden>
>> Sent: Tuesday, June 6, 2017 10:13:51 PM
>> Subject: Virtio-BLK/SCSI write requests and data payload checksums
>>
>> Hi,
>>
>>
>> ich have spend several hours debugging a strange checksum error issue and
>> finally found the cause, but I am totally unsure if whats happening
>> is correct or not.
>>
>> Imagine a Protocol like iSCSI which has a Data Digest and which receives its
>> data via zero copy straight from the guest kernel through Qemu and
>>
>> then out of the socket to the network. It calculates the CRC32C data digest
>> from the buffer it gets from Qemu. It totally relies thereby that the buffer
>> is not mangled after the write request has been submitted. But it seems this
>> assumption is not true.
>>
>> [...] the contents of the buffer submitted to Qemu change while Qemu
>> processes
>> the write.
>> In the end several write requests follow and the /etc/network/interfaces file
>> has the right content, but
>> is this at all legal?
>
> Yes, it's ugly but it's legal. It probably doesn't happen on real hardware
> that computes the checksum after or during DMA and has some kind of buffer
> inside the board. But on virt there is only one copy until we reach the
> actual
> physical hardware.
okay, so it's no bug. and there is no way to detect that the page is dirty
(again). so i need a bounce buffer if i have data checksums?
Peter
>
> Paolo
>
>> If yes, checksum calculation of payload and zero copy
>> would not work together.
>