Re: [PATCH 1/9] Xen Share: Simplified I/O Mechanism

[Rusty Russell <rusty@rustcorp.com.au>]

On Tue, 2006-06-06 at 15:47 +0100, Harry Butterworth wrote:
> On Tue, 2006-06-06 at 15:35 +1000, Rusty Russell wrote:
> > This introduces a page "share" mechanism to xen: an alternative to
> > both cross-domain binding of event channels, and grant tables.
> 
> Why do you think an alternative to event channels and grant tables is
> needed?

Fundamentally, I think having a simplified mechanism for inter-domain
communication keeps us honest: we can benchmark against it and look at
the code size, if nothing else.

> Personally, I think there is a need for a more convenient _high-level_
> API that more directly meets the split-drivers' requirements for
> inter-domain messaging and bulk data transfer but this seems to me to be
> another low-level API and doesn't seem significantly more convenient to
> use than grant-tables and event-channels.

The isolation it provides forms a better basis for a higher-level
mechanism, IMHO.  Neither side really knows, or cares, where the events
and data are really going to.  There is no mapping of other domain's
memory, with all the trust and coordination issues that we had to deal
with (and didn't completely!) with the current mechanisms.

For example, if you wanted to use this as a remote mechanism for
communication with another machine, you could.  If you wanted to
substitute backends without the front end knowing, you could.  If the
frontend or backend dies, there is no restriction on cleaning up its
memory.

> Is the n>2-way sharing feature the only benefit over grant-tables or do
> you think there are other benefits to your approach?

Other than the above theoretical advantages, I found it far easier to
implement a Linux driver on top of this, than it was to implement it on
top of grant tables, event channel binding and xenbus.  Easier to
implement means easier to optimize, easier to port, and easier to debug.

Hope that clarifies!
Rusty.
-- 
 ccontrol: http://ccontrol.ozlabs.org