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

> > The first approach gives you a simple frontend at the expense of a
> > complicated backend, while the second one gives you a simple backend
> > at the expense of a complicated frontend.  It seems likely that there
> > will be more frontend implementations than backend, which suggests
> > that putting the HBA emulation in the backend is a better choice.
> I agree with your thoughts. On the other hand, I also consider that
> the "more frontend implementation" suggests each guest OS has each own
> emulation policy, therefore emulating on the frontend is suitable,
> maybe. It's very difficult to decide which approach I should take. 
> Each approach has both good points and bad points. :-<
> 
> However, I would like to take the first approach, emulation on the
> backend, according to your and James Smart-san's advise, and to start
> implementation. :-)
It's a tricky decision, but I think this is the best path.

> > The main difference from a performance point of view is that the
> > second approach will use a ring for each device, whereas the first has
> > a single ring shared across all devices, so you'll get more requests
> > in flight with the second scheme.  I'd expect that just making the
> > rings larger would have more effect, though, and that's easier when
> > there's just one of them.
> I expect the Netchannel2 for solving performance issues.
It'll avoid this particular issue, yes.

> > Looking through the SCSI spec, I don't think we're going to be able to
> > get away with passing requests through from the frontend all the way
> > to the physical disk without sanity checking the actual CDB in the
> > backend.  There are a couple of commands which look scary:
...
> > What this means is that the REPORT LUNS issue fundamentally isn't
> > restricted to just the REPORT LUNS command, but instead affects an
> > unknown and potentially large set of other commands.  The only way I
> > can see to deal with this is to white-list commands individually once
> > they've been confirmed to be safe, and have the backend block any
> > commands which haven't been checked yet.  That's going to be a fair
> > amount of work, and it'll screw up the whole ``transparent pass
> > through'' thing, but I can't see any other way of solving this problem
> > safely.
> I will take the approach that start with mandatory SCSI commands by
> white-list, and expands the other commands.
Thank you.

Steven.

Attachment: signature.asc
Description: Digital signature

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