All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] USB support
Date: Sat, 05 Nov 2005 18:10:29 +0100	[thread overview]
Message-ID: <436CE785.10806@bellard.org> (raw)
In-Reply-To: <200511051731.24176.info@vruppert.de>

Volker Ruppert wrote:
> Hi,
> 
> 
>>The following features are implemented:
>>
>>- PCI UHCI USB controller (I finally decided to implement UHCI because I
>>know it better than OHCI and because Bochs has a similar driver. Of
>>course it would still be very interesting to have an equivalent OHCI
>>controller for non PC targets and an EHCI controller for USB 2.0 devices).
> 
> 
> I compared the Qemu USB controller with the Bochs one using Ralph Brown's 
> pcifg utility and found two different things.
> - Bochs USB appears at function 2 of the PIIX3
> - Bochs USB uses PIRQ line INTD
> You can find both things in the PIIX3 documentation.

I'll try to update that.

> I tried the Qemu USB implementation with Win98 here. The hubs are detected 
> correctly, but it makes Win98 hang on shutdown.

I only tested with a Linux 2.4 guest OS. The USB mouse is working in X11 
and the USB hubs seem to work too.

>>- Linux host USB redirector to use the USB 1.1 host devices which are
>>not requested by the host OS (i.e. no host driver is loaded for them).
>>It is *very* limited and buggy at the moment, but I was able (once !) to
>>mount a disk-on-key flash device.
> 
> 
> I guess the host OS doesn't like modifing data on a mounted devices. It might 
> be okay for input-only devices. I cannot try it here, since it requires root 
> permissions.

I will add a documentation once it works better, but here are some 
information :

1) The host OS must not use the USB device. It means in particular that 
no host OS driver must be present for that device. The solution I am 
using is to rename the host kernel module "usb-storage.o" to 
"usb-storage.o.disabled" so that it is not loaded by Linux. Then QEMU 
can exclusively access to the corresponding host storage USB device. The 
same apply to every other type of USB devices.

2) In order not to launch QEMU as root, I changed the permissions in 
/proc/bus/usb : chown -R myuid /proc/bus/usb. I am sure it is possible 
to find a better solution !

3) Isosynchronous USB packets are not redirected yet, so host webcams 
have no chance to work.

Fabrice.

  reply	other threads:[~2005-11-05 17:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05 14:45 [Qemu-devel] USB support Fabrice Bellard
2005-11-05 16:31 ` Volker Ruppert
2005-11-05 17:10   ` Fabrice Bellard [this message]
2005-11-05 17:24     ` Lonnie Mendez
2005-11-06 14:11       ` Fabrice Bellard
2005-11-13  1:00         ` [Qemu-devel] [patch] " Oliver Gerlich
2005-11-13 21:47           ` Fabrice Bellard
2005-11-05 23:39     ` [Qemu-devel] " Matthew Mastracci
2005-11-06  2:04 ` [Qemu-devel] " Mark Williamson
2005-11-06  2:10   ` Paul Brook
2008-02-09 15:34 Marek Zelem
2008-02-10 13:06 ` Arnon Gilboa

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=436CE785.10806@bellard.org \
    --to=fabrice@bellard.org \
    --cc=qemu-devel@nongnu.org \
    /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.