Re: virtio scsi host draft specification, v3

[Stefan Hajnoczi]

On Wed, Jun 29, 2011 at 9:33 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
> On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
>> If, however, we decide to expose some details about the backend, we
>> could be using the values from the backend directly.
>> EG we could be forwarding the SCSI target port identifier here
>> (if backed by real hardware) or creating our own SAS-type
>> identifier when backed by qemu block. Then we could just query
>> the backend via a new command on the controlq
>> (eg 'list target ports') and wouldn't have to worry about any protocol
>> specific details here.
>
> Besides the controlq command, which I can certainly add, this is
> actually quite similar to what I had in mind (though my plan likely
> would not have worked because I was expecting hierarchical LUNs used
> uniformly).  So, "list target ports" would return a set of LUN values to
> which you can send REPORT LUNS, or something like that?

I think we're missing a level of addressing.  We need the ability to
talk to multiple target ports in order for "list target ports" to make
sense.  Right now there is one implicit target that handles all
commands.  That means there is one fixed I_T Nexus.

If we introduce "list target ports" we also need a way to say "This
CDB is destined for target port #0".  Then it is possible to enumerate
target ports and address targets independently of the LUN field in the
CDB.

I'm pretty sure this is also how SAS and other transports work.  In
their framing they include the target port.

The question is whether we really need to support multiple targets on
a virtio-scsi adapter or not.  If you are selectively mapping LUNs
that the guest may access, then multiple targets are not necessary.
If we want to do pass-through of the entire SCSI bus then we need
multiple targets but I'm not sure if there are other challenges like
dependencies on the transport (Fibre Channel, SAS, etc) which make it
impossible to pass through bus-level access?

> If I understand it correctly, it should remain possible to use a single
> host for both pass-through and emulated targets.

Yes.

>> Of course, when doing so we would be lose the ability to freely remap
>> LUNs. But then remapping LUNs doesn't gain you much imho.
>> Plus you could always use qemu block backend here if you want
>> to hide the details.
>
> And you could always use the QEMU block backend with scsi-generic if you
> want to remap LUNs, instead of true passthrough via the kernel target.

IIUC the in-kernel target always does remapping.  It passes through
individual LUNs rather than entire targets and you pick LU Numbers to
map to the backing storage (which may or may not be a SCSI
pass-through device).  Nicholas Bellinger can confirm whether this is
correct.

Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/