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... > 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? > > 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. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
