Nicholas A. Bellinger wrote: > On Thu, 2010-04-01 at 10:15 +0200, Hannes Reinecke wrote: >> Hi all, >> > > Greetings Hannes, > > Just a few comments on your proposal.. > >> [Topic] >> Handling of invalid requests in virtual HBAs >> >> [Abstract] >> This discussion will focus on the problem of correct request handling with virtual HBAs. >> For KVM I have implemented a 'megasas' HBA emulation which serves as a backend for the >> megaraid_sas linux driver. >> It is now possible to connect several disks from different (physical) HBAs to that >> HBA emulation, each having different logical capabilities wrt transfersize, >> sgl size, sgl length etc. >> >> The goal of this discussion is how to determine the 'best' capability setting for the >> virtual HBA and how to handle hotplug scenarios, where a disk might be plugged in >> which has incompatible settings from the one the virtual HBA is using currently. >> > > Most of what you are describing here in terms of having a kernel target > enforce underlying LLD limitiations for LUNs is already available in TCM > v3.x. Current TCM code will automatically handle the processing of a > single DATA_SG_IO CDB generated by KVM Guest + megasas emulation that > exceeds the underlying LLD max_sectors, and generate the multiple > internal se_task_t's in order to complete the original I/O generated by > KVM Guest + megasas. > Hmm, yes. > This is one example but the main underlying question wrt to TCM and > interaction with Linux subsystems has historically been: > > What values should be enforced by TCM based on metadata presented by TCM > subsystem plugins (pSCSI, IBLOCK, FILEIO) for struct block_device, and > what is expected to be enforced by underlying Linux subsystems > presenting struct block_device..? > > For the virtual TCM subsystem plugin cases (IBLOCK, FILEIO, RAMDISK) the > can_queue is a competely arbitary value and is enforced by the > underyling Linux subsystem. There are a couple of special cases: > > *) For TCM/pSCSI, can_queue is enforced from struct scsi_device->queue_depth > and max_sectors from the smaller of the two values from struct Scsi_Host->max_sectors > and struct scsi_device->request_queue->limits.max_sectors. > > *) For TCM/IBLOCK, max_sectors is enforced based on struct request_queue->limits.max_sectors. > > *) For TCM/FILEIO and TCM/RAMDISK, both can_queue and max_sectors are > set to arbitrarly high values. > > Also I should mention that TCM_Loop code currently uses a hardcoded > struct scsi_host_template->can_queue=1 and ->max_sectors=128, but will > work fine with larger values. Being able to change the Linux/SCSI > queue depth on the fly for TCM_Loop virtual SAS ports being used in KVM > guest could be quite useful for managing KVM Guest megasas emulation I/O > traffic on a larger scale.. > And my question / topic here is how to handle a hotplug capability in these cases: What happens if a device / HBA is plugged in with different / lower capabilities than those announced? Can we change the announced settings for the HBA on the fly? > The other big advantage of using TCM_Loop with your megasas guest > emulation means that existing TCM logic for >= SPC-3 T10 NAA naming, PR, > and ALUA emulation is immediately available to KVM guest, and does not > have to be reproduced in QEMU code. > I'm not doubting that using TCM_loop here would be advantageous. But I have to find a solution for folks just wanting to run on plain /dev/sdX. And I need to find a common ground here to argue with the KVM folks, whose main objection against the megasas emulation is this issue. Either way would be fine by me, I just think we should come to a common understanding. My initial idea here was to just pass the request back as partially completed; that would solve the issue nicely. Sadly the SCSI midlayer interprets partial completion always as an error :-( Would've been really neat. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- 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
