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

[Steven Smith <steven.smith@xxxxxxxxxxxxx>]

> 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
> 
>

signature.asc
Description: Digital signature

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