[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and
From: |
Jan Kiszka |
Subject: |
[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices) |
Date: |
Thu, 08 Jul 2010 16:42:26 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
David S. Ahern wrote:
>
> On 07/08/10 01:49, Jan Kiszka wrote:
>> David Ahern wrote:
>>> Per the EHCI specification a USB 2.0 host controller is comprised of one
>>> high-speed controller and 0 to N USB 1.1 companion host controllers (UHCI
>>> or OHCI) for low- and full-speed devices. Port routing and control logic
>>> determines which HC owns a particular port. See Sections 1.2 and 4.2 of the
>>> EHCI specification.
>>>
>>> http://www.intel.com/technology/usb/download/ehci-r10.pdf
>>>
>>> In essence a USB 2.0 bus has N ports. Those N ports can be controlled by
>>> either the companion controller or the ehci controller. The ports default
>>> to the companion controller. At boot if the OS has an EHCI host driver it
>>> can take control of the ports by default and when a low/full speed device
>>> is connected switch the port to a companion controller. After looking into
>>> this for the past 6+ weeks, the port routing and control logic gets rather
>>> complex to implement in qemu.
>>>
>>> To keep the implementation simple I propose keeping the UCHI/OHCI and EHCI
>>> buses implemented independently -- using the 0 option for the number of
>>> companion host controllers.
>>>
>>> When USB devices are created they are assigned to a specific bus:
>>>
>>> .-------------------.
>>> | device creation |
>>> '-------------------'
>>> / \
>>> -------------------- --------------------
>>> | UHCI controller | | EHCI controller |
>>> -------------------- --------------------
>>> | |
>>> -------------------- --------------------
>>> | Low/Full speed dev | | High speed devices |
>>> -------------------- --------------------
>>>
>>> qemu's emulated devices already know which USB version they are compatible
>>> with, so no need to probe for it. Host based devices can default to ehci
>>> (or uhci if preferred) and then use the speed information obtained from the
>>> scan to determine if the device should be attached to the uhci bus instead.
>> What about the case the guest does not use EHCI (or later on XHCI)? Can
>> we avoid attaching device of higher speed to those buses then? And
>> migrate them over once the guest disables EHCI (XHCI), e.g. by unloading
>> the related module? Otherwise, those devices will be unusable for the
>> guest IIUC.
>>
>> Jan
>>
>
> There really is no way of knowing if the guest loads or unloads the
> kernel module. For example, recent seabios images configure and enable
> the ehci controller -- and leave it enabled on the hand off to the guest
> OS.
We only need to behave like real HW does. If Seabios leaves the
controllers in an improper state, then it's a Seabios bug that can be
fixed independently.
> Also, the guest driver enables and disables the periodic and
> asynchronous lists as needed. Given that I'm not sure there is a way to
> know 100% that the guest does not support ehci.
According to quick glance at the spec, the logic to route a device to
the companion controller is !EHCI-configured || !port.EHCI-owned. So
detection should be a non-issue...
> Then there is the
> complexity of moving devices between the USB buses as the driver is
> loaded and unloaded.
...but I guess this is the actual problem. What makes moving devices
between buses so complex in QEMU?
>
> As an alternative, what about enhancing the -usb option to note the
> maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to
> uhci/ohci for compatibility with current design. Then ehci can be
> enabled by the user. Enabling v2 means v1 is also enabled. Similarly
> when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled.
I think we either go for your current proposal as an intermediate
solution and fix the routing later on, or we find a way to do it
correctly on first run.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux