From: Stefan Hajnoczi <stefanha@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: maxk@kernel.org, qemu-devel <qemu-devel@nongnu.org>,
David Ahern <dsahern@gmail.com>
Subject: [Qemu-devel] Re: UHCI idle detection
Date: Tue, 4 Jan 2011 12:47:52 +0000 [thread overview]
Message-ID: <AANLkTinQiytPotBd=PsSmLSV2WTN3YDW=MW6ORx_1_bO@mail.gmail.com> (raw)
In-Reply-To: <4D230EE8.5090609@redhat.com>
On Tue, Jan 4, 2011 at 12:13 PM, Gerd Hoffmann <kraxel@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
next prev parent reply other threads:[~2011-01-04 12:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-04 11:48 [Qemu-devel] UHCI idle detection Stefan Hajnoczi
2011-01-04 12:13 ` [Qemu-devel] " Gerd Hoffmann
2011-01-04 12:47 ` Stefan Hajnoczi [this message]
2011-01-04 13:43 ` Gerd Hoffmann
2011-01-04 13:49 ` Anthony Liguori
2011-01-04 14:16 ` Gerd Hoffmann
2011-01-04 14:22 ` Anthony Liguori
2011-01-04 15:51 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AANLkTinQiytPotBd=PsSmLSV2WTN3YDW=MW6ORx_1_bO@mail.gmail.com' \
--to=stefanha@gmail.com \
--cc=dsahern@gmail.com \
--cc=kraxel@redhat.com \
--cc=maxk@kernel.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).