Re: [Xen-devel] [Patch 0/7] pvSCSI driver

[Jun Kamada <kama@xxxxxxxxxxxxxx>]

Hi James-san,

Thank you for your comments.

On Fri, 14 Mar 2008 15:16:44 -0400
James Smart <James.Smart@xxxxxxxxxx> wrote:

> Jun Kamada wrote:
> > -----
> > 1.) Allow specifying arbitrary mapping between Dom0's SCSI tree and
> >     Guest's SCSI tree. This includes "lun".
> >             ( Dom0's IDs [host1:channel1:id1:lun1] --->
> >                         Guest's IDs [host2:channel2:id2:lun2] )
> 
> It would really be nice, when considering a model of FC NPIV, or IOV-based
> ports, where you allow a model where the mapping can be stronger and done
> in a single step. E.g. map everything from a particular scsi_host into the 
> DomU.
> 
> Note: I'm not lobbying for a change in emulation, but rather trying to 
> automate
> the arbitrary and individual mappings when there is a higher level (relative 
> to
> the scsi tree) association to the DomU.

I have a same thoughts that the interface such like wild-card (for
example 1:0:*:*) is needed.


> Note: given that channel # is specific to the host#,
>               and id # is specific to the channel #,
>               and lun # is specific to the id #
>        there's no real reason why they couldn't be the same, or at least
>        overlap, with the Dom0 values. It's all up to whomever is doing
>        the transformation or emulation.
>
> > 2.) Guest has responsibility to have mapping and transform between
> >     Dom0's IDs and Guest's IDs. It depends on guest OS's implementation
> >     which level(e.g. only "host" or all of 4-tuples or no-transform) of
> >     mapping/transformation will be supported.
> >     If guest decides to support lun transformation and in case of
> >     "lun1 != lun2", the guest's frontend driver should maintain LUN
> >     value in CDB data structure. 
> 
> Wow. This seems odd. In my mind, this really is based on the abstraction
> you choose between the DomU and Dom0. You're either exporting SCSI Disks,
> SCSI targets, or SCSI Hosts. Each of these dictates differences in the way
> the emulation is done.
> 
> I would have thought the translation always occurs on the Dom0 side.

I would like to take backend side emulation approach as mentioned on
another mail. Thank you for your advise.


> > 3.) As for REPORT LUNS command, Dom0 performs munging.
> 
> This is in line with my last statement - it's on the Dom0 side.
> 
> > 4.) Dom0 accepts only LOGICAL UNIT RESET command.
> 
> Note: At least for Linux stacks, and I know it's true for older Windows
> releases as well, the scsi stacks don't generate LOGICAL UNIT RESETS.
> They are either Target Resets or Bus Resets.

This is very difficult issue and there is no good solution. :-<


> > 5.) Of course, the backend driver performs sanity check of IDs that the
> >     guest already transformed.
> 
> And if you're checking it - why are you (the Dom0) managing the 
> transformation ?
> Sounds like the work got done twice in your proposal.
> 
> -- james
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


Best regards,

-----
Jun Kamada



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel