[Qemu-devel] Re: UHCI idle detection

[Anthony Liguori <anthony@codemonkey.ws>]

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