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
