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

[Jun Kamada <kama@xxxxxxxxxxxxxx>]

Hi Steven-san and James-san,

Thank you for your comments.

We have had a internal discussion based on your comments and reached
following thoughts. I consider that the thoughts can provide both 
flexibility and ease of implementation.

We would like to start modification of the pvSCSI driver according to
the thoughts. How do you think about it? The thoughts is reasonable? 
If you have any comments, could you please?


-----
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] )
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. 
3.) As for REPORT LUNS command, Dom0 performs munging.
4.) Dom0 accepts only LOGICAL UNIT RESET command.
5.) Of course, the backend driver performs sanity check of IDs that the
    guest already transformed.


And I would like to implement pvSCSI frontend driver for Linux by
following mapping/transformation policy. (Please note that another guest
OS such as Windows can take another policy, of cource.)

- The guest looks identical tree as Dom0 looks except for "host".
  (This comes by the reason that arbitrary "host" mapping is difficult
  for current Linux implementation.)
- Of course, the guest's tree is sparse if some LUNs were not attached
  to the guest. Linux kernel allows the situation that lun=0 does not
  exist, therefore sparse tree is not a problem.


Best regards,


On Mon, 10 Mar 2008 12:00:59 +0000
Steven Smith <steven.smith@xxxxxxxxxxxxx> wrote:

> > Problems discussed in this context, what the portion of whole SCSI
> > tree should be exposed to guest and how the numbering logic of guest's
> > tree should be, is very fundamental and difficult, I think.
> > 
> > In my current thought, following two options are reasonable solutions.
> > How do you think about them? Could you please comment me?
> > 
> > Option 1 (LUN assignment)
> > - Specify the assignment like below:
> >   "host1:channel1:id1:lun1"(Dom0) -> "host2:channel2:id2:lun2"(guest)
> >   The lun1 must be same as the lun2.
> > - Munging :-) REPORT LUNS command on Dom0 according to the number of
> >   LUNs actually attached to the guest.
> I think this is the most flexible approach.
> 
> One thing to watch out for here is that some old systems get quite
> confused if lun0 is missing but some of the higher luns are present.
> That's easy to handle if you allow an arbitrary mapping between dom0
> and guest luns, but is hard if you require them to be identical.  This
> might not be an issue in the cases which we care about, though.
> 
> > Option 2 (Target Assignment)
> > - Specify the assignment like below:
> >   "host1:channel1:id1"(Dom0) -> "host2:channel2:id2"(guest)
> >   All LUNs under id1 are assigned to one guest.
> > - Munging for LUN is not needed.
> > 
> > For each option, how host/bus/device reset command should be?
> It's possible that we'll be able to get away with just supporting
> LOGICAL UNIT RESET commands, and completely ignoring lower granularity
> resets.  I'm not sure how widely supported they are on actual
> hardware, but it might be good enough for a first implementation.  You
> might even be able to get away with not supporting any kind of reset
> at all, and just accepting that error recovery is going to suck.
> 
> Steven.
> 
> > On Wed, 5 Mar 2008 13:34:48 +1100
> > "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:
> > 
> > > > This kind of suggests that we should be plumbing things through to the
> > > > guest with a granularity of whole targets, rather than individual
> > > > logical units.  The alternative is a much more complicated scsi
> > > > emulation which can fix up the LUN-sensitive commands.
> > > 
> > > I think we should probably have the option of doing either.
> > > 
> > > > Allowing this kind of mapping sounds reasonable to me.  It would also
> > > > make it possible (hopefully) to add support for some of the weirder
> > > > SCSI logical unit addressing modes without changing the frontends
> > > > (e.g. hierarchical addressing with 64 bit LUNs).  That might involve a
> > > > certain amount of munging of REPORT LUNS commands in the backend,
> > > > though.
> > > 
> > > Not sure how much it matters, but any 'munging' of scsi commands would
> > > be a real drag for Windows drivers. The Windows SCSI layer is very
> > > strict on lots of things, and is a real pain if you are not talking to a
> > > physical PCI scsi device.
> > > 
> > > James
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> > 
> > Jun Kamada
> > 
> > 


-----
Jun Kamada



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