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

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.

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.

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.

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