From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49241 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pa7GE-0007UQ-5f for qemu-devel@nongnu.org; Tue, 04 Jan 2011 08:49:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pa7GB-0001cS-6G for qemu-devel@nongnu.org; Tue, 04 Jan 2011 08:49:12 -0500 Received: from mail-iw0-f173.google.com ([209.85.214.173]:38602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pa7GB-0001cI-3H for qemu-devel@nongnu.org; Tue, 04 Jan 2011 08:49:11 -0500 Received: by iwn40 with SMTP id 40so15729307iwn.4 for ; Tue, 04 Jan 2011 05:49:10 -0800 (PST) Message-ID: <4D232550.7030701@codemonkey.ws> Date: Tue, 04 Jan 2011 07:49:04 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4D230EE8.5090609@redhat.com> <4D2323EF.4020900@redhat.com> In-Reply-To: <4D2323EF.4020900@redhat.com> 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: Gerd Hoffmann Cc: Stefan Hajnoczi , maxk@kernel.org, qemu-devel , David Ahern On 01/04/2011 07:43 AM, Gerd Hoffmann wrote: > 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. I think we're long overdue for a paravirtual mouse. Basically, a virtio version of xenkbd-front.c. In fact, it's probably possible to reuse the protocol. Regards, Anthony Liguori > >>>> 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