qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.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, 04 Jan 2011 13:13:28 +0100	[thread overview]
Message-ID: <4D230EE8.5090609@redhat.com> (raw)
In-Reply-To: <AANLkTik7=8A74eBwO4QUb7J9ERMkrdBLu6uB7=5bEKGq@mail.gmail.com>

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.

> I was hoping to find a solution to detect an "idle" UHCI state, i.e. a
> stable state where the guest is waiting for UHCI to report events and
> the guest isn't issuing new transfers.  If the idle state can be
> detected, then UHCI stops its frame timer and protects the frame list
> and other control structure guest memory pages.
 >
> 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.

cheers,
   Gerd

  reply	other threads:[~2011-01-04 12:14 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 ` Gerd Hoffmann [this message]
2011-01-04 12:47   ` [Qemu-devel] " Stefan Hajnoczi
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=4D230EE8.5090609@redhat.com \
    --to=kraxel@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=maxk@kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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).