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.