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

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

[David S. Ahern]

USB 2.0 leverages companion UHCI or OHCI host controllers for full and
low speed devices. I do not see an appropriate means for doing that bus
transition and could use some suggestions.

I've read through the code for the "legacy" path in handling USB devices
(-usbdevice CLI arg and usb_add monitor command), and I am now working
on the new path (now that I know about it).

As I understand the code at this point it is a top down setup: device
added, bus found, device attached.

    --------------------
   |   Qemu USB admin   |   - adding/removing devices
   |     interface      |   - showing device list
    --------------------
             |
    --------------------
   |   USB controller   |
    --------------------
             |
    --------------------
   |  USB device model  |   - emulated devices (e.g., hw/usb-serial)
   |    (or driver )    |   - host devices
    --------------------


ie., key point is the expectation that the bus to which the device is
assigned is known early in the code path.

For USB devices the bus to attach it to should be determined
automatically when the device is attached. Something along the lines of:

    --------------------
   |   Qemu USB admin   |
   |     interface      |
    --------------------
             |
    --------------------      --------------------
   |   EHCI controller  |--->|    UHCI / OHCI     |
    --------------------      --------------------
             |                         |
    --------------------      --------------------
   |  USB device model  |    |  USB device model  |
   |    (or driver )    |    |    (or driver )    |
    --------------------      --------------------
         high speed             full / low speed


To know which bus to attach it to the device needs to be queried/probed
for basic information - something the current architecture does not have.

Suggestions?

David

P.S. I skimmed the USB 3.0 spec and it has the same design: super speed
devices are attached to the new 3.0 controller, high speed to ehci and
low/full to uhci/ohci.

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

[Gerd Hoffmann]

On 05/25/10 15:40, David S. Ahern wrote:
>
> USB 2.0 leverages companion UHCI or OHCI host controllers for full and
> low speed devices. I do not see an appropriate means for doing that bus
> transition and could use some suggestions.

Hmm.  Well.  That doesn't really fit into the qdev tree model ...

> As I understand the code at this point it is a top down setup: device
> added, bus found, device attached.

Devices are always added to some bus.  In the case of usb the devices 
can also be attached/detached.  Emulated devices usually attached right 
after creating them.  Host devices are attached when a matching physical 
device shows up.

> ie., key point is the expectation that the bus to which the device is
> assigned is known early in the code path.

Yes.  You can even specify the bus you want attach the device to.

>      --------------------      --------------------
>     |   EHCI controller  |--->|    UHCI / OHCI     |
>      --------------------      --------------------
>               |                         |
>      --------------------      --------------------
>     |  USB device model  |    |  USB device model  |
>     |    (or driver )    |    |    (or driver )    |
>      --------------------      --------------------
>           high speed             full / low speed
>
>
> To know which bus to attach it to the device needs to be queried/probed
> for basic information - something the current architecture does not have.

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?

> Suggestions?

Maybe it makes more sense to look at ehci/uhci as *one* (physical) 
device with multiple interfaces?  They share the physical ports after 
all, at least on real hardware.

The tricky case is assigning host devices, right?  For the emulated ones 
we can probably could get away by simply forcing them into 2.0-only or 
1.1-only mode depending on which bus they got attached to.

cheers,
   Gerd

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

[Kevin Wolf]

Am 26.05.2010 13:47, schrieb Gerd Hoffmann:
> On 05/25/10 15:40, David S. Ahern wrote:
>>
>> USB 2.0 leverages companion UHCI or OHCI host controllers for full and
>> low speed devices. I do not see an appropriate means for doing that bus
>> transition and could use some suggestions.
> 
> Hmm.  Well.  That doesn't really fit into the qdev tree model ...
> 
>> As I understand the code at this point it is a top down setup: device
>> added, bus found, device attached.
> 
> Devices are always added to some bus.  In the case of usb the devices 
> can also be attached/detached.  Emulated devices usually attached right 
> after creating them.  Host devices are attached when a matching physical 
> device shows up.
> 
>> ie., key point is the expectation that the bus to which the device is
>> assigned is known early in the code path.
> 
> Yes.  You can even specify the bus you want attach the device to.
> 
>>      --------------------      --------------------
>>     |   EHCI controller  |--->|    UHCI / OHCI     |
>>      --------------------      --------------------
>>               |                         |
>>      --------------------      --------------------
>>     |  USB device model  |    |  USB device model  |
>>     |    (or driver )    |    |    (or driver )    |
>>      --------------------      --------------------
>>           high speed             full / low speed
>>
>>
>> To know which bus to attach it to the device needs to be queried/probed
>> for basic information - something the current architecture does not have.
> 
> 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.

>> Suggestions?
> 
> Maybe it makes more sense to look at ehci/uhci as *one* (physical) 
> device with multiple interfaces?  They share the physical ports after 
> all, at least on real hardware.
> 
> The tricky case is assigning host devices, right?  For the emulated ones 
> we can probably could get away by simply forcing them into 2.0-only or 
> 1.1-only mode depending on which bus they got attached to.

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

Kevin

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

[Gerd Hoffmann]

   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.

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

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

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

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

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.

David

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

[Kevin Wolf]

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

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

[David S. Ahern]

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

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

[Johannes Stezenbach]

On Wed, May 26, 2010 at 08:00:33AM -0600, David S. Ahern wrote:
> On 05/26/2010 07:23 AM, Kevin Wolf wrote:
> > Am 26.05.2010 15:06, schrieb David S. Ahern:
> >>
> >> 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.
...
> > 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.
> 
> 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.

My understanding of the EHCI spec: It's best to see the
port router as a seperate device.  USB devices are not
connected directly to EHCI or [UO]HCI, they are connected
to the port router.  If the port routing is changed
one of the HCs will see a connect event, the other one
a disconnect event, i.e. the handling is as if you
had unplugged the cable from one HC and plugged in into
the other HC.

By default the bus is connected to [OU]HCI, but when the
OS loads an EHCI driver it will set the Configured Flag to change
the default routing to EHCI.  If the EHCI driver determines
a device is not high speed, it will change the routing for
that port back to [UO]HCI.  The port router will see a physical
unplug event so the EHCI driver can change the routing back to
EHCI on unplug.

I think a typical EHCI controller has more ports than a UHCI
or OHCI controller, this is why you see more companion controllers
in lspci.  I think this doesn't matter, the key point is that
there is a fixed connection in hw for each port to the port router.


Johannes