Re: Proposal for init/kexec/hotplug format for Xen

[Harry Butterworth <harry@hebutterworth.freeserve.co.uk>]

On Sun, 2005-02-27 at 16:39 -0600, Anthony Liguori wrote:
> Keir Fraser wrote:
> 
> >> What I'm thinking about right now is how to assign out ports for 
> >> notification.  It's somewhat non-trivial to figure out the best way 
> >> to manage that.  Any thoughts?
> >
> >
> > The difficulty may be that, in the case of normal SysV IPC you have a 
> > common OS instance to manage shmem namespaces and semaphores and so 
> > on. For IDC over Xen you do not have this luxury, unless you modify 
> > Xen, or you are building over higher-level communication primitives 
> > (which perhaps defeats the purpose).
> 
> This is what makes the OF directory structure so interesting.  The 
> per-domain OF structure could be used as an IDC namespace.  This 
> requires no additional modification to Xen (other than what the OF 
> structure would).
> 

Say you have an IDC API which allows services to be installed in
different domains and accessed remotely from other domains.

For resource discovery and hotplug, what you require is a service that
implements a publish and subscribe API, call it a registry for the sake
of argument.

When a driver domain boots, it can be passed the IDC API address of the
registry to use to publish the devices that it is serving.

When a guest domain boots, it can be passed the IDC API address of the
registry to use to discover the devices it is allowed to use.

When driver domains discover devices, they publish the availability of
the devices in their registry.

When guest domains boot, they connect to their registry to subscribe to
notification of device availability.  If the connection process has an
asynchronous completion then the protocol might specify that
notification for all devices already registered on connection is given
to the guest domain before completion of the connection process. This
allows the guest domain to know how long to wait for devices to appear
before continuing with the boot process.

When driver domains lose access to devices or discover new ones they
keep their registry updated which in turn notifies connected guest
domains.

If one of the classes of devices that can be advertised in a registry is
allowed to be a bus device which implements a registry interface then
you can implement a hierarchical space.

Also, there's no reason that the driver domains need to be directly
connected to the registry used by the guest domains.  You could for
example have the driver domain connect to a registry connected to a
domain implementing access control which would then republish the
availability of the devices in separate registries for a number of guest
domains according to the access control policy configured for those
guests.

Another option might be for a guest domain to republish the availability
of devices in a child registry for a child domain created out of the
resources of the guest domain.

Maybe you can think of how to construct something like this based around
the OF directory structure.

-- 
Harry Butterworth <harry@hebutterworth.freeserve.co.uk>



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click