Re: [Xen-devel] USB split driver

["Andrew D. Ball" <aball@xxxxxxxxxx>]

Thanks, Harry.  I know you've put a lot of work into this.

Peace.
Andrew

On Tue, 2006-10-03 at 18:10 +0100, Harry Butterworth wrote:
> I've updated this patch to compile against current unstable and
> implemented a new protocol which I think fixes the data integrity issue
> present in all previous versions where URBs were not correctly stalled
> on error.
> 
> In this version of the driver, an error in the BE causes the BE URB
> queue to stall and all URBs present and subsequently arriving in the BE
> to be unlinked and failed back to the FE.
> 
> The FE catches the unlinking URBs and hangs onto them until the
> callbacks of any failing URBs and any URBs explicitly unlinked by the FE
> driver as a result have completed.
> 
> After the FE error and unlink completions are quiesced, the FE retries
> any URBs that remain back to the BE, sending the first with a flag that
> clears the stall in the BE.
> 
> This was fairly ugly, and the locking is a bit of a nightmare.  The main
> problem is that the USB stack has the semantics that it guarantees that
> the URB queue will be stalled only until the URB completion returns
> which means that there is a requirement to to URB unlinking nested in
> the BE completion.
> 
> I have seen a couple of URB errors handled without the kernel crashing
> but I would expect there to be some bugs in this code somewhere.
> 
> Also the xenbus stuff has been stirred around a few times since I wrote
> it correctly and I have lost interest in proving to myself that the
> current hooks into xenbus are correct.  The state machines in
> ub_xb_channel and uf_xb_channel which coordinate with xenbus were
> derived by trial and error and unlike the rest of the code are not
> intended to be correct by design.
> 
> Someone has messed around with the usb stuff in the python code since
> the last version too, possibly to implement usb support for the HVM
> guests.  I changed this code to use "usbport" rather than usb and
> hopefully it won't conflict.  This is untested.
> 
> The driver used to be modular and an older version did correctly handle
> module load and unload in both the FE and BE including quiescing ongoing
> I/O.  I was told to simplify the driver and remove this functionality.
> The current version is therefore not modular.
> 
> I had some correspondence with the author of the USB over IP patch and
> we came to the conclusion that USB/IP does not address the stalling
> requirement above.  We were not 100% sure whether this is a problem but
> I think it probably is.  This driver might perhaps be a useful example
> of how to solve the problem for the USB/IP code.
> 
> I had put this work on hold waiting for an upstream merge of the other
> drivers in the hope that it would force a cleanup of some of the xenbus
> design.  Recently I discovered that I'll be leaving the IBM Xen team in
> the near future and I'm not sure how much more time I can spend on this
> so this is an attempt to get the driver in the best possible shape for
> someone else to pick up.
> 
> The xen core team should decide whether they really want a USB split
> driver at all or if they want to go with USB/IP or some common code
> approach.
> 
> As for this driver, the basic structure of the code is OK.  I think the
> locking is probably OK.  Lots more testing is required as well as
> regression tests for xm-test.  Some formatting issues probably remain
> too.  It's probably a bit too abstract for some of you---if so, you can
> always read the .ko files ;-)
> 
> Sniff tested against f426f6e646eb.
> 
> Signed-off-by: Harry Butterworth <butterwo@xxxxxxxxxx>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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