[Xen-devel] USB split driver

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

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>

latest-usb.patch
Description: Text Data

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