[Qemu-devel] USB Asynchronous I/O

[Qemu-devel] USB Asynchronous I/O

[Salil Bijur]

Hello,

I've been testing Bluetooth-USB in QEMU for an arm-based processor
with a Linux guest.

When a bluetooth dongle is added, there is a continuous sending of
bulk and interrupt packets synchronously (using the USBDEVFS_BULK
ioctl) making qemu extremely slow and unusable.
I wanted to know if it is a good idea to send these bulk and interrupt
transfers asynchronously using the SUBMITURB and REAPURBNDELAY ioctls
in a way similar as isochronous transfers in usb-linux.c.
Is there any reason why only isochronous packets are being sent
asynchronously when the same can be done for other types?

Thanks,
Salil

RE: [Qemu-devel] USB Asynchronous I/O

[Arnon Gilboa]

I believe you can do it similar to the way I did for isochronous
transfers in usb-linux.c.
Remember that using SUBMITURB and REAPURBNDELAY ioctls, you need to add
another signal and signal handler for the async bulk, and there might be
some issues in the ohci/uhci because they currently assume only
isochronous transfers are async. A minute ago I tried to implement the
bulk transfers using SUBMITURB and REAPURB (which blocks until response)
but it seems to hang qemu upon connecting a disk-on-key.

-----Original Message-----
From: qemu-devel-bounces+arnong=qumranet.com@nongnu.org
[mailto:qemu-devel-bounces+arnong=qumranet.com@nongnu.org] On Behalf Of
Salil Bijur
Sent: Wednesday, November 14, 2007 11:49 PM
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] USB Asynchronous I/O

Hello,

I've been testing Bluetooth-USB in QEMU for an arm-based processor with
a Linux guest.

When a bluetooth dongle is added, there is a continuous sending of bulk
and interrupt packets synchronously (using the USBDEVFS_BULK
ioctl) making qemu extremely slow and unusable.
I wanted to know if it is a good idea to send these bulk and interrupt
transfers asynchronously using the SUBMITURB and REAPURBNDELAY ioctls in
a way similar as isochronous transfers in usb-linux.c.
Is there any reason why only isochronous packets are being sent
asynchronously when the same can be done for other types?

Thanks,
Salil

Re: [Qemu-devel] USB Asynchronous I/O

[Salil Bijur]

On Nov 15, 2007 5:46 PM, Arnon Gilboa <arnon.gilboa@qumranet.com> wrote:
> I believe you can do it similar to the way I did for isochronous
> transfers in usb-linux.c.
> Remember that using SUBMITURB and REAPURBNDELAY ioctls, you need to add
> another signal and signal handler for the async bulk, and there might be
> some issues in the ohci/uhci because they currently assume only
> isochronous transfers are async. A minute ago I tried to implement the
> bulk transfers using SUBMITURB and REAPURB (which blocks until response)
> but it seems to hang qemu upon connecting a disk-on-key.
>

What about interrupt packets? For a bluetooth device, the interrupt
packets are sent almost every 2-3 ms. taking up most of the bandwidth.
These in turn called the synchronous ioctls hanging qemu for that
time. Making these asynchronous gives a timeout in the kernel's usb
subsystem.

Re: [Qemu-devel] USB Asynchronous I/O

[Paul Brook]

> there might be
> some issues in the ohci/uhci because they currently assume only
> isochronous transfers are async.

That's definitely incorrect. The USB mass storage emulation uses async bulk 
transfers.

Paul

RE: [Qemu-devel] USB Asynchronous I/O

[Arnon Gilboa]

Sorry, it was my mistake. I only meant it may require some changes in
ohci/uhci.

-----Original Message-----
From: Paul Brook [mailto:paul@codesourcery.com] 
Sent: Sunday, November 18, 2007 3:31 PM
To: qemu-devel@nongnu.org
Cc: Arnon Gilboa
Subject: Re: [Qemu-devel] USB Asynchronous I/O

> there might be
> some issues in the ohci/uhci because they currently assume only 
> isochronous transfers are async.

That's definitely incorrect. The USB mass storage emulation uses async
bulk transfers.

Paul