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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 9 Jan 2012, Roger Pau Monn�© wrote:
> > 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 ?
> 
> No, I think it's best that even is the driver domain is Dom0 the same
> procedure should be executed, and xenbackendd should be running in
> every driver domain, Dom0 included, toolstack should never execute
> hotplug scripts directly.

I agree.


> > 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.
> 
> Are we only going to use xenstore to share information between both
> domains (Dom0 <--> Driver domain)?

That would make things easier, but we have to be careful not turning
xenstore in an RPC style mechanism of communication because it is not
very good a that. In that case we would be better off with libvchan.


> I'm going to comment the vif case, but I think both vif and block
> devices should follow the same approach, and hotplug script execution
> has to be something "standard" and should not rely on the type of the
> device.

Right. However vif and block scripts need to be executed at different
points of the lifecycle of the VM.


> > 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
> 
> How does the toolstack tell a domain to create a device? Creating a
> xenstore entry like:
> 
> /local/domain/<domid>/backend/vif/...
> 
> does trigger the creation of a vif interface in the <domid> domain?

Yes, I think so.


> > � * backend kernel creates a virtual network interface vifNN
> > � * something in backend domain notices that this vifNN
> > �  � has appeared and consequently
> 
> This should be handled by xenbackendd (I know it will not exactly be
> xenbackendd, but let's call it that way to simplify things), since it
> should be listening to /local/domain/<domid>/backend/* for changes and
> react upon them.

I think this is wrong because we would be tying together the vif
creation with the script execution, while these two kinds of events
might need to be executed at different point in time (especially in the
block case). We need be flexible.
I would make xenbackendd listen to a different xenstore location,
maybe /hotplug/<domid>/*, so that the toolstack can explicitly ask
xenbackendd for something, making sure that it gets done before taking
other actions.


> > � * device setup script runs, enslaves vifNN to bridge, adds
> > �  � it to routing tables, gives it an address, etc.
> 
> Handled by hotplug scripts.
> 
> > � * something in backend domain domain tells toolstack vif is ready
> 
> Hotplug scripts should change backend state (and write the appropriate
> values) to notify everything when ok. Since xenbackendd is the one
> that executes the scripts, it should examine the exit code of the
> called hotplug script and write the exit status code and message if
> hotplug script execution is not successful. This values can be
> retrieved from the toolstack and notify the user if something failed.

Or the script could write the return value to /hotplug/<domid>/vif/state
itself. Either way should work.


> > � [ device is used ]
> > � * toolstack tells backend domain to destroy vif; perhaps entire
> > �  � xenstore directory is forcibly removed??
> 
> If entire xenstore directory is forcibly removed, how does xenbackendd
> know the parameters to pass to the hotplug script to shutdown the
> device? Do we have to keep a copy of this somewhere else (xenstore or
> create a xenbackendd private database)?

This problem would disappear if we use /hotplug/<domid> rather than
/local/domain/<domid>/backend to store the parameters.


> Here we have two cases, whether it is a shutdown or a destroy:
> 
> When doing a shutdown the toolstack should wait to get a notification
> from the driver domain that hotplug execution was done (either
> successfully or not) and then proceed with the removal of xenstore
> directory.
> 
> DomU closes device --> driver domain notices --> execution of hotplug
> scripts --> write result to xenstore --> toolstack reads results of
> hotplug teardown.
> 
> When doing a destroy, the toolstack should manually set the frontend
> state to closed, and thus force the execution of hotplug scripts in
> the driver domain? I know this has been a cause of discussion in
> previous patches, but I really don't see the problem with modifying
> the frontend status if the domain is already dead, it's just a way to
> force the unplug of the device and the execution of hotplug scripts.
> Normally the DomU should set the frontend status to closed, but since
> we killed it from the toolstack, it should be the toolstack itself the
> one in charge of setting the status to closed.

this problem would go away too if we use /hotplug/<domid> rather than
/local/domain/<domid>/backend to trigger xenbackendd events.

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