From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48529 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pa7Ac-00055h-2s for qemu-devel@nongnu.org; Tue, 04 Jan 2011 08:43:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pa7AU-0000WT-U7 for qemu-devel@nongnu.org; Tue, 04 Jan 2011 08:43:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pa7AU-0000WH-Hy for qemu-devel@nongnu.org; Tue, 04 Jan 2011 08:43:18 -0500 Message-ID: <4D2323EF.4020900@redhat.com> Date: Tue, 04 Jan 2011 14:43:11 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4D230EE8.5090609@redhat.com> 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 Hi, >> Windows guests needs some registry hackery and Linux guests some udev rules >> 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. Well, long-term this shouldn't be a big issue. I expect guest agents become commonplace soonish as some features require guest cooperation, so the guest agents can also care about this kind of tweaks. Also for linux we can try to send the changes to upstream udev to have it spread into linux distros. >>> 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. > > 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. remote wakeup is exactly that. Except that it doesn't kick the uhci directly but the port it is connected to, which isn't the same in case the device is connected using a usb hub. Which probably makes it tricky to re-use the remote wakeup callback for the idle detection. cheers, Gerd