Re: [LSF/VM TOPIC] Handling of invalid requests in virtual HBAs

[Hannes Reinecke <hare@suse.de>]

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@suse.de			      +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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html