[Xen-devel] USB split driver status

[harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I've just completed the second revision of the USB split driver patch
series.

This series of patches is the same as the last series except that I went
through and manually reformatted it to try to get the coding style
correct and address the style issues raised in feedback on the first
revision.

This series also fixes a regression I introduced when syncing up with
Ewan's xenbus changes; module loading and unloading now seems to be
working as reliably as it was before the xenbus change.

The current code is able to create a filesystem on a USB key and copy a
large file to it without miscompares.

The issues that I know about that remain with this code are as follows:

o - currently the code requires swiotlb=force.

o - The USB protocol requires stalling the URB queue during error
conditions.  This isn't done correctly yet which makes the code unsafe
for write access during error recovery.  The 2.4 code had this problem
as well---I only discovered it recently.

o - The USB-specific part of the interdomain protocol is using polling
for device discovery which is inefficient.  This is the same strategy as
the 2.4 code.

o - The resource pools are currently only allocating the minimum
resources required to avoid deadlock so performance will be resource
constrained.  This can be fixed either by implementing a larger static
resource allocation or improving the buffer_resource_provider to
implement a dynamic shared resource pool.  Either is fairly easy.

o - Isochronous URBs are untested.

o - My test machine is USB 1.2 and I've not yet tested with USB 2.0.

o - Suspend and resume is untested.  Domain migration is untested.

o - I've only ever tried to build the code for X86 and never X86_64.

o - Some API documentation for the xenidc code would be nice.

o - Automated tests integrated with the xm-test framework would be good
too.

Since the code is basically working, I'd like to get it into the tree
ASAP to give it wider exposure for more testing.  I'm guessing it's now
too late to get it in for 3.0 but hopefully it will be possible to get
it in for a point release in the not too distant future.

Any feedback on the patch series would be welcome, especially any
feedback on what changes or further work is required to get the code
into the tree.

Harry.


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