[Qemu-devel] Re: UHCI idle detection

[Gerd Hoffmann <kraxel@redhat.com>]

   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