[Xen-devel] Driver domains and hotplug scripts, redux

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Roger Pau Monné writes ("Re: [Xen-devel] RFC: Still TODO for 4.2?"):
> I don't know much about driver domains, but from what I've read they
> should be running something like NetBSD xenbackend and listen for
> xenstore events. Most of the functions that I've written on my hotplug
> series can be used to create a little daemon, that's not the problem,
> the problem is what can we use to synchronize hotplug script calling
> and libxl (what comes to mind is using a dedicated xenstore variable
> for each device, but someone might have a better idea).

This envisages devicer setup/teardown scripts in driver domains
running in a different way to those in the same domain as the
toolstack.  Are we sure this is a good idea ?

I think it would be preferable to have only one interface to device
scripts, which is used everywhere.  That interface would have to
involve initiation by the toolstack, and collection of resulting
success/failure/etc., via xenstore.

The sequence of events for vifs with a kernel-level backend needs
to go like this:
  * toolstack tells backend domain to create vif, via xenstore
  * backend kernel creates a virtual network interface vifNN
  * something in backend domain notices that this vifNN
    has appeared and consequently
  * device setup script runs, enslaves vifNN to bridge, adds
    it to routing tables, gives it an address, etc.
  * something in backend domain domain tells toolstack vif is ready
  [ device is used ]
  * toolstack tells backend domain to destroy vif; perhaps entire
    xenstore directory is forcibly removed??
  * backend kernel removes virtual network interface immediately
    and all routes, bridge enslavements, etc., are undone
  * something in backend notices the removal
  * device teardown script may need to remove eg firewall rules
  * when this is complete, the backend domain notifies the
    toolstack (how??)

For block devices with a kernel-level backend:
  * toolstack tells backend domain to create vbd
    parameters include: vbd number, target??, script??
  * something in backend domain notices this and consequently
  * device setup script runs, creates a suitable actual
    block device in backend domain
  * backend kernel picks up actual block device details and
    becomes available to guest
  * something in backend domain tells the toolstack all is well
  [ device is used ]
  * toolstack tells backend domain to destroy vbd; perhaps entire
    xenstore directory is forcibly removed??
  * backend kernel removes its actual backend and closes the
    block device, and somehow notifies userspace when this
    is done so that
  * device teardown script cleans up, including making actual
    block device go away (if it was one which the setup script
    created)
  * when this is complete, the backend domain notifies the
    toolstack (how??)

For block devices with a user-level backend:
  * toolstack tells backend domain to create vbd
    parameters include: vbd number, target??, script??
  * userland backend notices this, does its housekeeping
    and setup, and tells the toolstack all is well
  [ device is used ]
  * toolstack tells backend domain to destroy vbd; perhaps entire
    xenstore directory is forcibly removed??
  * userland backend removes its actual backend and closes the
    resources it was using, and
  * notifies the toolstack (how??)

Much of this seems to be covered by, or coverable by, the existing
xenstore protocol.  I think we just need to define in more detail
exactly how it should all work, and on each platform how the
"something"s work.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel