On Tue, 2010-04-13 at 21:09 +0400, Vladislav Bolkhovitin wrote: > Hannes Reinecke, on 04/13/2010 12:56 PM wrote: > > The general idea for the virtual HBA is that scatter-gather lists > > could be passed directly from the guest to the host (as opposed to > > abstract single I/O blocks only like virtio). > > But the size and shape of the sg lists is different for devices > > coming from different HBAs, so we have two options here (this is > > all done on the host side; the guest will only see one HBA): > > > > a) Adjust the sg list to match the underlying capabilities of > > the device. Has the drawback that we defeat the elevator > > mechanism in the guest side as the announced capabilities > > there do _not_ match the capabilities on the host :-( > > b) Adjust the HBA capabilities to the lowest common denominator > > of all physical devices presented to the guest. > > While this would save us from adjusting the sg lists, > > it still has the drawback the disk hotplugging won't > > work, as we can't readjust the HBA parameters in the > > guest after it's been created. > > > > Neither of which is really appealing. > > Why only a single virtual HBA should be used? Why not to have a > dedicated virtual HBA for each physical HBA? This way you wouldn't > have problems with capabilities and the need to have lowest common > denominator. Basically, it's a matter of another struct > scsi_host_template with possibly the same shared callback functions.. > > > My idea here would be to move all required capabilities > > to the device/request queue. > > That would neatly solve this issue once and for all. > > And even TGT, LIO-target, and SCST would benefit from this > > methinks. > > > > But this is exactly the discussion I'd like to have at LSF, > > to see which approach is best or favoured. > > > > And yes, I am perfectly aware that for a 'production' > > system one would be using a proper target emulator > > like LIO-target or SCST for this kind of setup. > > But first I have to convince the KVM/Qemu folks to > > actually include the megasas emulation. > > Which they won't until the above problem is solved. > > LIO doesn't support 1 to many pass-through devices sharing, so SCST in > the only option. Sorry, but this statement about your perceived limitiations wrt TCM/LIO is completely incorrect. Using a single passthrough backstore device (eg: plain /dev/sdX) with TCM/pSCSI (or any TCM subsystem plugin) has been supported since the dawn of time to allow for any number of TCM_Loop Virtual SAS Ports with SG_IO going into KVM Guest. The same is also true for LIO-Target (iSCSI) and TCM_FC (FCoE) ports as well regardless of TCM subsystem backstore. Perhaps you would be so kind to provide a TCM/LIO source code reference from where you came up with this make-believe notion..? --nab -- 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
