On Wed, Apr 27, 2011 at 11:47:03AM +0000, KY Srinivasan wrote: > On the host side, Windows emulates the standard PC hardware > to permit hosting of fully virtualized operating systems. > To enhance disk I/O performance, we support a virtual block driver. > This block driver currently handles disks that have been setup as IDE > disks for the guest - as specified in the guest configuration. > > On the SCSI side, we emulate a SCSI HBA. Devices configured > under the SCSI controller for the guest are handled via this > emulated HBA (SCSI front-end). So, SCSI disks configured for > the guest are handled through native SCSI upper-level drivers. > If this SCSI front-end driver is not loaded, currently, the guest > cannot see devices that have been configured as SCSI devices. > So, while the virtual block driver described earlier could potentially > handle all block devices, the implementation choices made on the host > will not permit it. Also, the only SCSI device that can be currently configured > for the guest is a disk device. > > Both the block device driver (hv_blkvsc) and the SCSI front-end > driver (hv_storvsc) communicate with the host via unique channels > that are implemented as bi-directional ring buffers. Each (storage) > channel carries with it enough state to uniquely identify the device on > the host side. Microsoft has chosen to use SCSI verbs for this storage channel > communication. This doesn't really explain much at all. The only important piece of information I can read from this statement is that both blkvsc and storvsc only support disks, but not any other kind of device, and that chosing either one is an arbitrary seletin when setting up a VM configuration. But this still isn't an excuse to implement a block layer driver for a SCSI protocol, and it doesn't not explain in what way the two protocols actually differ. You really should implement blksvs as a SCSI LLDD, too - and from the looks of it it doesn't even have to be a separate one, but just adding the ids to storvsc would do the work. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
