From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54143 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OWsJ8-0002fi-IK for qemu-devel@nongnu.org; Thu, 08 Jul 2010 10:42:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OWsJ7-0008GJ-0R for qemu-devel@nongnu.org; Thu, 08 Jul 2010 10:42:34 -0400 Received: from goliath.siemens.de ([192.35.17.28]:21798) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OWsJ6-0008F7-Kf for qemu-devel@nongnu.org; Thu, 08 Jul 2010 10:42:32 -0400 Message-ID: <4C35E3D2.5020206@siemens.com> Date: Thu, 08 Jul 2010 16:42:26 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1278521907-13582-1-git-send-email-daahern@cisco.com> <4C358319.9070401@web.de> <4C35D6D3.6020408@cisco.com> In-Reply-To: <4C35D6D3.6020408@cisco.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] ehci: uhci-ehci co-existence (handling v1.1 and v2 devices) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "David S. Ahern" Cc: qemu-devel@nongnu.org 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