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

[David S. Ahern]

On 07/08/10 08:42, Jan Kiszka wrote:
> 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...

Per Section 2.2.3 if there are no companion controllers then the port
ownership handoff is not supported. The configured flag you mentioned
(Section 2.3.8) is not applicable if port routing is not supported. Port
routing as defined in the EHCI spec is the complexity part that I think
should be avoided.

> 
>> 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?

>From a terminology perspective my reference to moving devices between
buses is separate from the ehci port routing which is way more complex
(a very subtle point).

In my first cut at this I was using the following to switch buses and it
works fine:

+void usb_device_migrate(USBDevice *dev, USBBus *bus)
+{
+    BusState *bus_state = &bus->qbus;
+
+    /* remove from current */
+    usb_device_detach(dev);
+
+    dev->qdev.parent_bus = bus_state;
+
+    /* add to given one */
+    if (bus->nfree == 1) {
+        usb_create_simple(bus, "usb-hub");
+    }
+    do_attach(dev);
+    return;
+}


> 
>>
>> 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.

Moving devices from ehci to uhci and vice versa can be implemented later
if there is agreement that a simplified ehci model (ie, no companion
controllers) is acceptable.

David

> 
> Jan
>