Re: Interdomain comms

[Andrew Warfield <andrew.warfield@gmail.com>]

Hi Harry,

  These two comments seem more about the immediate control tool plans
than about a generic comms mechanism.

> There are two different issues here:

These seem pretty concise as regards the new control tool plans:

> 1) Having one Xend might be correct at the moment. The _assumption in
> the guests_ that there is only one Xend is technically a minor flaw. If,
> for example, the guest got an idc_address for Xend, the guest would be
> decoupled from the design choice of one or many Xends.

I think we are all keen to move in the direction of having no xend but
rather a small set of single purpose daemons that handle specific
tasks and map well on to the emerging security primitives.

> 2) The Xend introductions.  The weird aspect about these is that they
> are a triangular protocol with phases initiated by xend in two
> directions, potentially at the same time. I'm more used to control flow
> following resource dependencies, for example: server tells third-party
> about resource availability; third-party assigns resources to clients;
> clients connect directly to server. This is also triangular but if you
> put the server at the top and bottom it becomes a stack ordered by
> dependencies.  I think stacks are much less confusing than triangles and
> have more easily defined interlocks and less risk of introducing timing
> windows.  I think it ought to be possible to get the security right for
> a stack solution as well as the triangle solution. Maybe a secuity
> expert could provide some help.

The triangular connection setup in the current code is a little grim
and something that will change very soon.  The two relevant bits of
this are the event channel and the shared page address on setting up a
new device channel.  Keir added support for unbound event channels
quite a while ago, and the control tools/drivers just haven't evolved
to take advantage of them yet.  The store will be used for additional
connection set-up state, such as shared page addresses.

Connection setup this way does map on to the connect/listen semantics
that Mike has been advocating.  For example, on a request to add a new
frontend, the backend driver will create a simple state machine for
the new device channel and assign an unbound event channel to it.  It
will then move out of this (unbound) "listening" state when the front
end connects to the event channel and sends the first notification.

So we still have something in the middle, but it's a much more simple
and generic thing.

a.