WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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

<Prev in Thread] Current Thread [Next in Thread>