[Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices)

[Jan Kiszka]

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