Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] [PATCH V13 3/5] libxl: add pvusb API"):
> There are effectively four states a device can be in, from the
> 'assignment' point of view:
> 
> 1. Assigned to the normal Linux device driver(s) for the USB device
> 
> 2. Assigned to no driver
> 
> 3. Assigned to usbback, but not yet assigned to any guest
> 
> 4. Assigned to a guest

Thanks for your clear explanation (of which I will snip much).

> Additionally, each USB "device" has one or more "interfaces".  To
> assign a "device" to usbback in the sysfs case means assigning all of
> the "interfaces".  The code seems to assume that different interfaces
> from the same device can be assigned to different drivers.

It is indeed the case that in principle a single USB device with
multiple interfaces can be assigned to multiple different drivers.

> Regarding Ian's comments:
> 
> Since "assigned to the guest" and "listed under the pvusb xenstore
> node" are the same thing, is it even *possible* to (safely) unassign
> the device from usbback before removing the xenstore nodes?

It might be possible to remove some of the xenstore nodes but leave
others present, so that usbback detaches, but enough information
remains for libxl to know that Xen still `owns' the device.

But, surely usbback needs to cope with the notion that the device
might disappear.  USB devices can disappear at any time.

> It's not clear to me under what conditions 3->2 might fail,

As an example, someone might press ^C on `xl usb-detach'.

> or what could be done about it if it did fail.

The most obvious reason for it failing is that something somewhere
still held onto the device.  (For umounting filesystems, and detaching
block devices, this happens a lot.)  So if the detach from usbback
fails would probably be possible to simply retry it.

> Regarding 2->1, again it's not clear that there's anything libxl can
> do.  Reloading the driver's module might reset it enough to pick up
> the (now unassigned) USB devices again; other than that, rebooting is
> probably the best option.

I think re-attempting the bind may work.  USB devices can be flaky.

> It's also not clear to me, if some functions succeed in being
> reassigned and others fail, whether it's best to just try to assign as
> many as we can, or better to go back and un-assign all the ones that
> succeeded.

Unless explicitly requested, I don't think the system should create
situations some interfaces are assigned to host drivers and some to
usbback.

And, I'm a fan of `crash-only software': in general, if a failure
occurs, the situation should just be left as-is.  The intermediate
state needs to be visible and rectifiable.

This approach to software state machines avoids bugs where the system
gets into `impossible' states, recovery from which is impossible
because the designers didn't anticipate them.

It would be tolerable if the recovery sometimes involves `lsusb' and
echoing things into sysfs, but it would be better if not.

> Perhaps the best approach code-wise is to change the "goto out" on
> failure of unbind_usbintf() into a "continue".  That way:
> 
> 1. All interfaces which can be re-assigned are re-assigned (and work
> as much as possible)
> 
> 2. All interfaces which can be unbound but not re-assigned are at
> least unbound (so that reloading the original driver might pick them
> up)

I certainly don't mind the software trying to do as much of its task
as possible.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel