On Mon, Feb 7, 2011 at 10:27 AM, Boaz Harrosh <openosd@xxxxxxxxx> wrote: > On 02/07/2011 09:57 AM, Nicholas A. Bellinger wrote: >> *) Guest OS specific para-virtualized SCSI driver packages (similar to >> virtio-blk) performing SCSI I/O handoff into passthrough interface via >> SCSI I_T nexues, with proper T10 WWN Port and LUN naming provided from >> underlying TCM v4.x infrastructure (eg: full compat w/ existing SPC-3 >> capable cluster clients) >> > > I agree with the 2 above points on a better scsi-based Kernel-only > passthrough code in the KVM host. But the 3rd point, could we not used any > one of the few LLDs that already exist? I think there are already 3 of these, > no? including the one Microsoft submitted. It could be done either way but there are some unique properties of a virtio-scsi HBA. A virtio-scsi HBA can be implemented on the host as a vhost-scsi in-kernel device (like vhost-net today). That allows it to hand off requests to the SCSI target without switching to userspace. It can interact directly with the TCM fabric module because it is in the kernel, like TCM_Loop today. The alternative is to emulate an existing HBA and that would be done in QEMU userspace, at which point you need an interface to talk to the SCSI target stack inside the kernel - this already exists today with QEMU SCSI emulation and scsi-generic/BSG devices but is not the same as fabric-level support. Virtio is extensible and this has proven essential for evolving and optimizing the I/O path. If we choose an interface whose specification we cannot modify, then we're stuck with its feature set and performance limitations. Guest support is important though, so it's worth looking more at well-supported SCSI HBAs and see if there is a middle path to take. Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
