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

[Hannes Reinecke <hare@suse.de>]

Vladislav Bolkhovitin wrote:
> Hello Hannes,
> 
> Hannes Reinecke, on 04/01/2010 12:15 PM wrote:
>> Hi all,
>>
>> [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.
> 
> If I understand correctly, you need to allow several KVM guests to share
> the same physical disks?
> 
No, the other way round: A KVM guest is using several physical disks,
each of which coming via a different HBA (eg sda from libata, sdb from lpfc
and the like).
So each request queue for the physical disks could be having different
capabilities, while being routed through the same virtual HBA in the
KVM guest.

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.

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.

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