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

[Steven Smith <steven.smith@xxxxxxxxxxxxx>]

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