Re: [Qemu-devel] scsi-generic and max request size

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2010-12-22 at 14:27 +0100, Christoph Hellwig wrote:
> On Wed, Dec 22, 2010 at 02:54:54PM +0100, Hannes Reinecke wrote:
> > Most modern HBAs are using separate codepaths for streaming/block I/O
> > anyway,
> 
> That's not true at all.  Every normal HBA justs passes normal SCSI
> commands to the SCSI targets.  It's just raid adapters that take special
> commands, and the megaraid one is extremly special as it actually
> emulates a few SCSI commands even in RAID mode, which almost no other
> HBA does.  Strictly speaking we should not allow scsi-generic with
> megaraid_sas, except for the separate passthrough channels that the real
> hardware has for things like tape drives.

Actually, I would put it differently here.

scsi-generic is -fundamentally- busted for HBA HW emulation since you
simply cannot convey the limits of the underlying real HBA.

If you are on top of usb-storage with a 120K max_sectors and try to
emulate a piece of HBA with no such limitation how in hell do you make
you guest know not to give your >120K requests at a time and what do you
do if it does ? You're stuffed basically...

Hence, the only way scsi-generic can make sense imho, is for something
like vscsi which I'm doing now, which is just a transport and does have
the ability to convey to the client/guest some of those limitations...
provided it can get to them in the first place (see the discussion, it's
really non trivial, which makes /dev/sg even less useful even for normal
userspace :-)

In the Megaraid case, the fact that it has this separate read/write
channel on the contrary should make it -easier- to solve that problem
typically by allowing the emulation layer to construct sequences of
READ/WRITE requests that match the limitations. IE. Ie makes
scsi-generic a possibility while it would otherwise (and is) broken in
unfixable ways with other HBA emulation.

> > However, since Alex Graf is facing similar problems with the AHCI HBA of
> > his maybe we could retry again ...
> 
> AHCI is a ATA adapter, and should never be used with scsi-generic for
> disks.  Only for the ATAPI-attached cdroms/tapes/etc it could be used,
> although it's quite pointless.

Right, but in that case (cdroms etc...) it would have the exact same
problem. I'm not familiar with AHCI HW, and so I don't know whether
there's a way for the HW to convey "limits" to the driver, but if not,
then operating via scsi-generic would be busted the same way anything
else is.

Basically, scsi-generic cannot work for emulating an HBA. In fact, I
would go as far as saying that it's not possible to generically emulate
an HBA that just pass-through any SCSI command, simply due to the
inability to convey those limits.

vscsi is a special case (and other "paravirt" drivers that may exist)
because being explicitely designed for acting as such transports, they
-do- convey the necessary limit information. I don't know iscsi but I
would be surprised if it didn't provide similar facilities.

So what we need here is a way for qemu to retrieve those reliably when
using scsi-generic. That's the missing piece of the puzzle on my side.

Cheers,
Ben.