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. 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. Then there is the complexity of moving devices between the USB buses as the driver is loaded and unloaded. 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. David
