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

[Jun Kamada <kama@xxxxxxxxxxxxxx>]

Hi,

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.

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?


Best regards,


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



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