Re: [RFC] [PATCH] SCSI passthrough for virtio-blk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Freitag, 29. August 2008 schrieb Hannes Reinecke:
> > ([<0000000000435e66>] schedule+0x32e/0x7ec)
> >  [<000000000043659e>] schedule_timeout+0xba/0x10c
> >  [<00000000004358da>] wait_for_common+0xbe/0x1a8
> >  [<000000000027ec3e>] blk_execute_rq+0x86/0xc4
> >  [<0000000000282768>] sg_io+0x1a4/0x360
> >  [<0000000000282f8c>] scsi_cmd_ioctl+0x2bc/0x3f0
> >  [<00000000002c3108>] virtblk_ioctl+0x44/0x58
> >  [<000000000027ff18>] blkdev_driver_ioctl+0x98/0xa4
> >  [<000000000027ffd8>] blkdev_ioctl+0xb4/0x7f8
> >  [<00000000001e1572>] block_ioctl+0x3a/0x48
> >  [<00000000001bca0a>] vfs_ioctl+0x52/0xdc
> >  [<00000000001bcb0a>] do_vfs_ioctl+0x76/0x350
> >  [<00000000001bce6e>] sys_ioctl+0x8a/0xa0
> >  [<000000000011282c>] sysc_tracego+0xe/0x14
> >  [<0000020000114286>] 0x20000114286
> 
> I'm tempted to say 'not my fault'; the submitted SCSI request on
> the _host_ hangs and doesn't come back.
> Looks more like a SCSI problem on the host ...

It is a guest process trace.

Anyway, after you suggested to look at the len field it appeared to me, that 
the new code sets the data_len, sense_len and changes the number of reported 
bytes to random values even if the host returns VIRTIO_BLK_S_UNSUPP.

Moving these assignments to the VIRTIO_BLK_S_OK case seems to fix it.
Can you test if SG_IO still works for you after applying this patch:

Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx>
---
 drivers/block/virtio_blk.c |   17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

Index: kvm/drivers/block/virtio_blk.c
===================================================================
--- kvm.orig/drivers/block/virtio_blk.c
+++ kvm/drivers/block/virtio_blk.c
@@ -50,9 +50,17 @@ static void blk_done(struct virtqueue *v
 	while ((vbr = vblk->vq->vq_ops->get_buf(vblk->vq, &len)) != NULL) {
 		int error;
 		unsigned int bytes;
+
+		bytes = blk_rq_bytes(vbr->req);
 		switch (vbr->status) {
 		case VIRTIO_BLK_S_OK:
 			error = 0;
+			if (blk_pc_request(vbr->req)) {
+				vbr->req->data_len = vbr->in_hdr.residual;
+				bytes = vbr->in_hdr.data_len;
+				vbr->req->sense_len = vbr->in_hdr.sense_len;
+				vbr->req->errors = vbr->in_hdr.status;
+			}
 			break;
 		case VIRTIO_BLK_S_UNSUPP:
 			error = -ENOTTY;
@@ -61,15 +69,6 @@ static void blk_done(struct virtqueue *v
 			error = -EIO;
 			break;
 		}
-
-		if (blk_pc_request(vbr->req)) {
-			vbr->req->data_len = vbr->in_hdr.residual;
-			bytes = vbr->in_hdr.data_len;
-			vbr->req->sense_len = vbr->in_hdr.sense_len;
-			vbr->req->errors = vbr->in_hdr.status;
-		} else
-			bytes = blk_rq_bytes(vbr->req);
-
 		__blk_end_request(vbr->req, error, bytes);
 		list_del(&vbr->list);
 		mempool_free(vbr, vblk->pool);



_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization

[Index of Archives]     [KVM Development]     [Libvirt Development]     [Libvirt Users]     [CentOS Virtualization]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux