On 19.07.2011, at 18:08, Christoph Hellwig wrote: > I've mentioned this a few times before, but just to make sure it's not > lost: > > This is a really bad idea for adding to qemu. It's not a controller that > actually speaks a plain SCSI protocol to disks, but a RAID controller, that > has it's own command set for data plan operation, and minimal support for > a few SCSI CDBs around it. I also supports passthrough channels for > CDROMs and other periphals, but using those with disks is not recommended > by LSI, thus explicitly disabled in most drivers and most certainly not > tested. So it fits the qemu model, especially if using scsi-generic > undeneath pretty badly and I don't think it helps us in practice. I don't understand where your reluctance comes from. Conceptually, it's basically the same as having a virtio-blk driver also exporting a scsi interface, which is the perfect case wrt performance. So worst case what do we get? Worst case we get a working block adapter that can handle disk I/O pretty straight forward and is comparable to AHCI. Best case, we can also use SGIO on top of it. Either way, we get something that's a lot faster than the current LSI parallel SCSI adapter and also calls itself "SCSI", thus has drivers for a good bunch of OSs. I don't see how anything would go against this adapter - we really have nothing to lose. If you want to sit down and write an emulation layer for an even better (recent) SCSI HBA, please, go ahead and do so. This one is the best SCSI adapter we'd have in Qemu at the time of its commit though and can at least help us straighten out our internal APIs. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
