From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45079 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pa6Is-0005b7-LK for qemu-devel@nongnu.org; Tue, 04 Jan 2011 07:47:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pa6Ir-0000vA-B6 for qemu-devel@nongnu.org; Tue, 04 Jan 2011 07:47:54 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:57046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pa6Ir-0000v0-6t for qemu-devel@nongnu.org; Tue, 04 Jan 2011 07:47:53 -0500 Received: by wyg36 with SMTP id 36so15777785wyg.4 for ; Tue, 04 Jan 2011 04:47:52 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D230EE8.5090609@redhat.com> References: <4D230EE8.5090609@redhat.com> Date: Tue, 4 Jan 2011 12:47:52 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: UHCI idle detection List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: maxk@kernel.org, qemu-devel , David Ahern On Tue, Jan 4, 2011 at 12:13 PM, Gerd Hoffmann wrote: > On 01/04/11 12:48, Stefan Hajnoczi wrote: >> >> CPU utilization is a known issue with UHCI emulation. =A0I spent a short >> time poking around the code and USB specifications trying to come up >> with a way to detect "idle" periods where we don't need to poll the >> frame list at 1000 Hz. > > Check out > > http://cgit.freedesktop.org/spice/qemu/log/?h=3Dusb.3 > > It adds remote wakeup support to uhci, hub and hid emulation. =A0This all= ows > the guest to suspend the usb bus when it is idle, the 1000 Hz wakeup goes > away then. > > Only problem with that is guests don't do that by default because there i= s > way too much broken hardware out there. =A0That includes the current qemu= usb > hid emulation which advertises remote wakeup support although it isn't > implemented :( > > Windows guests needs some registry hackery and Linux guests some udev rul= es > to enable remote wakeup permanently. That commit inspired me to look at UHCI. If the solution requires modifying the guest then it is not widely useful. >> When the guest writes to those memory pages again in order to issue a >> new USB transaction, we catch the write. =A0UHCI unprotects the guest >> memory pages and turns the frame timer back on. > > It isn't that simple. =A0"idle" state depends on the usb devices too. Wit= h a > usb tablet connected (and no remote-wakeup being used) uhci will poll the > tablet in regular intervals and the usb tablet will either send the next > event in the queue or NACK the transfer in case there is no event availab= le. Is there something preventing USB tablet emulation from using a non-polling approach? Devices need to be able to kick UHCI when data becomes available. Stefan