Re: [Xen-devel] RFC: Creation of virtual bus, hook-up of Xen devices

[Andrew Warfield <andrew.warfield@xxxxxxxxx>]

> >I think you want to query each backend and find out what devices it has.
> >I'm not sure if the enumeration function should be generic or
> >device-specific.  Our current device-specific approach could probably be
> >changed to be generic but in a first instance it would be quickest to
> >implement this using the existing "queries" since there are only two
> >device types.
> 
> Well, there are three now with USB.  And requiring the guest kernels to
> know it all seems silly.  It's actually pretty simple to do in a generic
> fashion.

I thought that the issue of enumerating interfaces and supporting
multiple backends was one of the major reasons that we were looking at
restructuring the control tools.  I think it makes a whole lot more
sense to have the list of devices and related state for each domain in
a persistent store/registry in dom0, primarily because it gives us a
point of indirection to allow backend restarts/hotswaps and means
other control tools can be added to look at the same state without
modifying the drivers or control messages.

This is vaguely what I think domain startup should look like with new
tools.  Bear in mind that it is quarter to nine on a saturday morning.
 These probably need a bit more thought, but I think these are along
the lines of what I have talked to keir about in the past.  Setting up
net/block interfaces for a new domain looks something like:

1. During domain creation, xend pushes a list or interfaces under the
new domain's part of the registry:

   /domn/blkifs/0/[each bit of state]

2. xend kicks each associated backend interface with an
FE_CREATE(domid) control message.  Each backend driver then scans the
registry for interfaces under its control and registers them.

3. As the domain starts up, its driver probes the registry for
enumeration, and then wires up interfaces based on the details there.

This is clearly more vague than it should be.  If anthony's new C
control tools are sufficiently functional, then maybe we can make some
fast progress in this direction though.  In general I like breaking
out state management because it gets us away from per-driver protocols
to manage simple state across front and backend.  It might even be
nice to see if we could come up with a clear general mechanism for
signalling shared memory/event channel setup along these lines as
well.

a.


-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel