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

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 2/3/2016 at 02:11 AM, in message
<22192.61775.427189.268007@xxxxxxxxxxxxxxxxxxxxxxxx>, Ian Jackson
<Ian.Jackson@xxxxxxxxxxxxx> wrote: 
> 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. 

Indeed "unassign from usbback, but listed under pvusb xenstore" is
a confusing state. usb-list can list it but guest can not see it. 
What user can do under that state is: reattempt usbdev_remove, if it 
succeeds, everything is cleaned up, that's the best result; but 
possibly it still fails (for example, in my testing, always cannot 
rebind to original driver), in this case, the confusing state will 
be lasting, and the device could not be removed, this is worse.

>  
> 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.

Could I understand that this way is acceptable? That means: removing 
xenstore, and as much as we could (on failure of "unbind from usbback"
or "bind to original driver", don't "goto out", just "continue").

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


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