qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH 1/2 v1] blkdrv: Add queue limits parameters for sg block drive
Date: Thu, 23 Aug 2012 13:08:50 +0100

On Thu, Aug 23, 2012 at 11:52 AM, Paolo Bonzini <address@hidden> wrote:
> Il 23/08/2012 12:08, Stefan Hajnoczi ha scritto:
>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]