Thread (20 messages) 20 messages, 6 authors, 2012-08-24

Re: [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive

From: Stefan Hajnoczi <hidden>
Date: 2012-08-23 12:08:57
Also in: qemu-devel

On Thu, Aug 23, 2012 at 11:52 AM, Paolo Bonzini [off-list ref] wrote:
Il 23/08/2012 12:08, Stefan Hajnoczi ha scritto:
quoted
quoted
I'm still trying to understand the extent of the problem.

The problem occurs for _USB_ CD-ROMs according to Ben.  Passthrough of
USB storage devices should be done via USB passthrough, not virtio-scsi.
 If we do USB passthrough via the SCSI layer we miss on all the quirks
that the OS may do based on the USB product/vendor pairs.  There's no
end to these, and some of the quirks may cause the device to lock up or
corruption.

I'd rather see a reproducer using SAS/ATA/ATAPI disks before punting.
This issue affects passthrough: either an entire sg device or at least
a SG_IO ioctl (e.g. a non-READ/WRITE SCSI command).

To reproduce it, check host queue limits and guest virtio-scsi queue
limits.  Then pick a command that can exceed the limits and try it
from inside the guest :).
Yes, so much is clear.  But does it happen _in practice_?  Do initiators
actually issue commands that are that big?
Here I think we need to err on the side of caution.  A user passes
through a tape drive or exotic SCSI device.  They run a vendor utility
inside the guest that issues a command that exceeds the host block
queue limits.

Passing through limits is intended to make SCSI device passthrough
work, in all cases.

Is the number of real cases where it happens small?  Probably.  I
still think we should make passthrough bulletproof.

Stefan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help