Hi Avi,

On Thu, 2008-07-03 at 05:51 +0000, SourceForge.net wrote:
> Bugs item #2009439, was opened at 2008-07-03 11:21
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2009439&group_id=180599
...
> Summary: data corruption with virtio-blk
> 
> Initial Comment:
> kvm-userspace : kvm-70-138-g163308a
> 
> With a kernel from linux-2.6.git (v2.6.26-rc8-89-ge1441b9), data
> corruption is seen on block devices when exported through virtio. Once
> a block device is mounted and unmounted in a guest, the kernel   is
> not able to find a filesystem in the block device when  being
> remounted. This is seen from the host as well.

I think the below fixes the data corrupter, but I'm still tracking down
another issue where the guest is hanging waiting for I/O to complete
with the latest virtio-blk backend.

Cheers,
Mark.

Subject: [PATCH] kvm: qemu: Fix virtio-blk data corrupter

Fix a typo in "avoid fragmented virtio-blk transfers by copying"
which causes data corruption.

See also:

  https://sf.net/tracker/?func=detail&atid=893831&aid=2009439&group_id=180599

Signed-off-by: Mark McLoughlin <[EMAIL PROTECTED]>
---
 qemu/hw/virtio-blk.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index c88f477..88dc086 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@ -186,7 +186,7 @@ static void virtio_blk_handle_output(VirtIODevice *vdev, 
VirtQueue *vq)
            for (i = 1; i < req->elem.out_num; i++) {
                size_t len;
 
-               len = MIN(req->elem.in_sg[i].iov_len,
+               len = MIN(req->elem.out_sg[i].iov_len,
                          req->size - offset);
                memcpy(req->buffer + offset,
                       req->elem.out_sg[i].iov_base,
-- 
1.5.5.1




--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to