All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
To: xen-devel@lists.xensource.com
Cc: mark.williamson@cl.cam.ac.uk
Subject: USB virt 2.6 status
Date: Thu, 02 Jun 2005 18:32:05 +0100	[thread overview]
Message-ID: <1117733525.7334.67.camel@localhost> (raw)
In-Reply-To: <1116841630.6579.17.camel@localhost>

Summary (since last status):

The 2.6 USB virt driver can now mount a filesystem in a 2.6 FE domain
from my USB key driven by a 2.6 USB BE driver domain.  Have successfully
done a small amount of I/O with miscompare checking.

Happy Happy Joy Joy.

Perhaps 2 weeks away from submitting a patch---want to fix items marked
*** below first.

Details:

I spent some time implementing USB protocol emulation in the back-end to
handle the USB control requests that were failing (starting with the
get-descriptor request) but then discarded the emulation code when I
discovered that the problem was due to a bug in the FE
(usb_pipein( urb->pipe ) returns 0x00 or 0x80 and was being assigned to
a single bit bit-field). I'm not sure why this didn't cause a problem
for the 2.4 driver.  The 2.4 back-end also doesn't seem to correctly map
all of the FE buffer if a transfer is > 4k but doesn't start at a 4k
boundary.  After fixing the transfer direction bug, the control requests
all sprang into life. The other bug might not be an issue since all the
bulk transfers I've seen so far have been aligned.

Managed to mount the FS on the USB key but the data was being corrupted.
I did some testing with a file full of random data and a recent dd
implementation with support for O_DIRECT to discover that 4K I/O was OK
but 8K or larger I/0 would sometimes swap around 4K chunks of data
within an I/O.

This turned out to be because I wasn't preserving the correct URB
serialisation---I had assumed that URBs didn't have order dependencies
and was sometimes issuing them out of order.

After reviewing the URB submission path and ensuring correct
serialisation, the I/O started working.

I spent a couple of days fixing module unload of the BE.  Previously it
only worked if the uhci-hcd module was unloaded before the usbback
module. Now it works either way around and I'm not aware of any
constraints on module loading/unloading.

I put in a kernel option to compile tracing (printfs for debugging) into
the usb FE and BE.

Still to do:

***Implement URB unlink/timeout functionality.  This part of the USB api
has changed since 2.4. The 2.6 code currently asserts if an unlink is
attempted and doesn't maintain any timeouts.

***Finish porting remaining 2.4 code for back and front-ends for
interrupt and isochronous transfers.

Support for USB devices with multiple interfaces. The 2.4 code is broken
in this area.  The 2.6 code refuses to drive devices with multiple
interfaces. Need to claim and release all of the interfaces of a
multiple interface device in one go.

BE uses allocate_empty_lowmem_region but there doesn't seem to be an
equivalent free function for module unload.  Need to fix this memory
leak.

Grant table support.

Review linux driver model reference counting.

Review error return codes.

***Sync up with latest xend rewrite and latest unstable (my snapshot is a few months old now).

***Implement support in vm-tools.

***Update copyright notices.

***Create and submit patch.

Testing of different USB device types (esp blade centre CD drive).

2.6/2.4 interoperability.

Test when compiled into kernel rather than modular.

Testing of multiple back-ends/multiple front ends/multiple devices etc.

Testing on SMP guests?

  reply	other threads:[~2005-06-02 17:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-30  0:03 USB virt 2.6 status Harry Butterworth
2005-05-23  9:47 ` Harry Butterworth
2005-06-02 17:32   ` Harry Butterworth [this message]
2005-06-03 14:03     ` Mark Williamson
  -- strict thread matches above, loose matches on Subject: below --
2005-11-08  1:15 Harry Butterworth
2005-06-17 17:34 harry
2005-04-01 18:44 Harry Butterworth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1117733525.7334.67.camel@localhost \
    --to=harry@hebutterworth.freeserve.co.uk \
    --cc=mark.williamson@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.