Re: [Qemu-devel] RFC: ehci -> uhci handoff suggestions

["David S. Ahern" <daahern@cisco.com>]

On 05/26/2010 07:23 AM, Kevin Wolf wrote:
> Am 26.05.2010 15:06, schrieb David S. Ahern:
>>
>>
>> On 05/26/2010 06:48 AM, Gerd Hoffmann wrote:
>>>
>>>   Hi,
>>>
>>>>> USB devices can support both 1.1 and 2.0, right?  Who decides which
>>>>> protocol is used then?  I think the OS can speak 1.1 to the device even
>>>>> in case a ehci controller is present (but unused by the OS), right?
>>>>
>>>> AFAIK the OS must tell the EHCI that it should hand the device off to
>>>> the UHCI/OHCI companion before it can use it there.
>>>
>>> Huh?  Compatibility-wise it makes sense to do it the other way around
>>> (i.e. have it @ UHCI/OHCI by default and move to EHCI on request), so a
>>> OS which knows nothing about EHCI can cope.
> 
> Ah, the page referenced by David explains this, so what I knew is only
> half of it. There is a Configured Flag that tells if the EHCI is used -
> and only when the OS has activated the EHCI this way it needs to
> explicitly hand off per device.
> 
>>>> If they should be accessed via the EHCI or a companion controller
>>>> depends on what the OS requests. And USB 2.0 says that any device that
>>>> supports High Speed must also support Full Speed and therefore be
>>>> accessible using the companion (at least that's what I understand).
>>>
>>> Hmm, ok, so no shortcut even for emulated devices.  Not that it would
>>> have helped much as we have to cover host devices anyway.
>>>
>>> Also I think one ehci controller can have multiple uhci companion
>>> controllers.  At least lspci on my T60 suggests that:
> 
> Yes, I think any number is allowed, and from a specification point of
> view it's even okay to have no companion controller at all. You just
> couldn't use Low/Full Speed devices in the ports of that controller then.
> 
>>> 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>>> Controller #1 (rev 02)
>>> 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>>> Controller #2 (rev 02)
>>> 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>>> Controller #3 (rev 02)
>>> 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
>>> Controller #4 (rev 02)
>>> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
>>> Controller (rev 02)
>>>
>>> cheers,
>>>   Gerd
>>>
>>
>> Yes, that is the ehci feature to be implemented.
>>
>> My understanding is that the port routing happens internally to the host
>> controller based on device speed - section 4.2 (pag 64) of:
>> http://www.intel.com/technology/usb/download/ehci-r10.pdf
> 
> The routing may happen internally, but the OHCI/UHCI appears just like a
> normal controller to the OS. You can't access the devices on a companion
> with your EHCI driver.
> 
>> ehci does have more overhead from an emulation perspective, so it would
>> be best to keep mice, keyboard, serial ports, etc on the uhci/ohci bus
>> and have storage devices and webcams and such on ehci. And any
>> transition should happen automagically within the device model.
> 
> I think in reality things like keyboards are Low Speed anyway, so they
> would need to be handed off to a OHCI/UHCI anyway.
> 
> Any transition between High Speed (directly handled by EHCI) and
> Low/Full Speed (OHCI/UHCI companion controller) must not happen
> automagically, but be requested by the guest OS. And you probably don't
> want to re-implement UHCI or OHCI inside the EHCI emulation, so you
> can't keep things inside the EHCI device model.
> 
> Kevin


I'm still confused by the guest OS interaction -- more code/spec reading
I guess.

Key points are that lspci in the VM shows both buses, and the qemu
monitor would still scan both buses and show devices. And definitely no
code duplication - some kind of movement to current uhci/ohci ports is
what I am after.

David