Re: [Qemu-devel] RFC: ehci - uhci handoff suggestions
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
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
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
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
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
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
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
[Qemu-devel] RFC: ehci - uhci handoff suggestions
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.
