> Am 07.06.2017 um 01:17 schrieb Paolo Bonzini <[email protected]>: > > > > ----- Original Message ----- >> From: "Peter Lieven" <[email protected]> >> To: "qemu block" <[email protected]> >> Cc: "Paolo Bonzini" <[email protected]>, [email protected], >> [email protected], "Max Reitz" <[email protected]>, >> "Michael S. Tsirkin" <[email protected]> >> 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. >
