From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33371 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pa5m5-0003Y3-Hi for qemu-devel@nongnu.org; Tue, 04 Jan 2011 07:14:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pa5m4-0007Eu-AR for qemu-devel@nongnu.org; Tue, 04 Jan 2011 07:14:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pa5m3-0007Ee-Vx for qemu-devel@nongnu.org; Tue, 04 Jan 2011 07:14:00 -0500 Message-ID: <4D230EE8.5090609@redhat.com> Date: Tue, 04 Jan 2011 13:13:28 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: UHCI idle detection List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: maxk@kernel.org, qemu-devel , David Ahern On 01/04/11 12:48, Stefan Hajnoczi wrote: > CPU utilization is a known issue with UHCI emulation. I 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=usb.3 It adds remote wakeup support to uhci, hub and hid emulation. This allows 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 is way too much broken hardware out there. That 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 rules to enable remote wakeup permanently. > I was hoping to find a solution to detect an "idle" UHCI state, i.e. a > stable state where the guest is waiting for UHCI to report events and > the guest isn't issuing new transfers. If the idle state can be > detected, then UHCI stops its frame timer and protects the frame list > and other control structure guest memory pages. > > When the guest writes to those memory pages again in order to issue a > new USB transaction, we catch the write. UHCI unprotects the guest > memory pages and turns the frame timer back on. It isn't that simple. "idle" state depends on the usb devices too. With 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 available. cheers, Gerd