> > 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.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home