WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] latest USB code including Xenidc documentation

To: xen-devel@xxxxxxxxxxxxxxxxxxx, ian.pratt@xxxxxxxxxxxx, keir.fraser@xxxxxxxxxxxx
Subject: [Xen-devel] latest USB code including Xenidc documentation
From: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 16 Dec 2005 16:51:07 +0000
Delivery-date: Fri, 16 Dec 2005 16:52:59 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Here again is the latest USB code split into the xenidc patch for
interdomain communication and the usb patch which depends on it.

The most significant change in this version of the code is the addition
of a chapter describing the Xenidc API to the interface document
docs/src/interface.tex.  I think there is now sufficient documentation
for people to have a look and start some discussion about whether a
high-level interdomain communication API like xenidc would be useful and
if so, whether the API presented would make a good starting point.

The USB code hasn't changed much apart from some style cleanups (mainly
shortening some names to help with formatting) and it still passes the
usual sniff test of mounting a filesystem on a USB key.

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

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.  I posted about this on the
usb-devel list and got some useful information.  The conclusion was that
a reasonable strategy on encountering an error would be to unlink all
the URBs outstanding for an endpoint in the backend and hold onto them
and queue any URBs received subsequently until the frontend driver had
had an opportunity to unlink any of the URBs that it wanted to unlink.
The remaining URBs would then be resubmitted.  I made a first attempt at
implementing this before discovering that the boundary conditions around
device resets and hotplug/removal were more subtle than I thought so I
reverted it.  I think I need to study the USB spec before I can attempt
this again.

o - An issue raised on the usb-devel mailing list was that there are a
few more commands which need to be implemented in the back end.  The
most difficult of which is "set configuration".  Set configuration
changes the interfaces a device presents and can't currently be
performed by the usb backend driver which is binding to the interfaces
of a specific configuration that has already been set.  The solution
seems to be to change the Linux USB stack to allow binding to the device
rather than the interfaces.  This would make it possible to support set
configuration and would make for a cleaner separation between the
actions performed by the back and front ends.  Without the Linux
changes, the current implementation is limited to devices for which set
configuration is not required.  Devices with multiple configurations
probably won't work properly.

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 - You no longer need to specify swiotlb=force because xen has a small
swiotlb turned on by default.  If you explicitly turn the swiotlb off,
the USB code will still be broken.

o - The USB-specific part of the interdomain protocol is using polling
for device discovery which is inefficient.  I looked into fixing this
and it won't be too hard to change the protocol so that the BE sends a
message to the FE to kick the FE into re-probing the BE.  This will make
the BE device state machine a bit more complicated.

o - Design documentation for the USB driver is required.

o - We might not want to keep the xenidc code.  There is now some
documentation for the xenidc API so you can have a look to see if you
think it is worth keeping.

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 - Automated tests integrated with the xm-test framework would be good.

o - Have now run some of the design issues by the USB mailing list.
Need to continue to do more of this.

Signed-off-by: Harry Butterworth <butterwo@xxxxxxxxxx>

Attachment: latest-xenidc-patch.gz
Description: GNU Zip compressed data

Attachment: latest-xenidc-patch.gz
Description: GNU Zip compressed data

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