On Tue, Jan 4, 2011 at 12:13 PM, Gerd Hoffmann <kra...@redhat.com> wrote: > 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.
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. 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. Stefan
