qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: UHCI idle detection


From: Gerd Hoffmann
Subject: [Qemu-devel] Re: UHCI idle detection
Date: Tue, 04 Jan 2011 14:43:11 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Red Hat/3.1.7-3.el6_0 Thunderbird/3.1.7

  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]