[Qemu-devel] udev 42-qemu-usb.rules considered harmful?

[Qemu-devel] udev 42-qemu-usb.rules considered harmful?

[Michael Tokarev]

Hello.

I noticed that "some" versions of linux guests shows quite
bad behavour of mouse cursor: it freezes after some idle
time, and when you move mouse, it jumps after some delay
to rather distant position.  So, mouse becomes "freezy/jumpy",
so to say.

Quite some painful debugging pointed to the following
udev rule:

---- /lib/udev/rules.d/42-qemu-usb.rules ----
#
# Enable autosuspend for qemu emulated usb hid devices.
#
# Note that there are buggy qemu versions which advertise remote
# wakeup support but don't actually implement it correctly.  This
# is the reason why we need a match for the serial number here.
# The serial number "42" is used to tag the implementations where
# remote wakeup is working.
#
ACTION=="add", SUBSYSTEM=="usb", ATTR{product}=="QEMU USB Tablet", ATTR{serial}=="42", TEST=="power/control", ATTR{power/control}="auto"
---- end ----

(And a few other similar rules, for other QEMU USB devices).

Removing this rule restores correct mouse behavour.

As far as I can see, this rule is to reduce polling interrupt
frequency, but apparently it does not help: any usb device
connected to guest, and the host CPU usage rises anyway, with
or without this rule.

Now the question: should we remove this rule?  Why it is needed
to start with?

(qemu version 1.1, but the same bad behavour happens with other
versions too).

Thanks,

/mjt

Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?

[Gerd Hoffmann]

On 10/17/12 10:41, Michael Tokarev wrote:
> Hello.
> 
> I noticed that "some" versions of linux guests shows quite

What is "some"?

> As far as I can see, this rule is to reduce polling interrupt
> frequency, but apparently it does not help: any usb device
> connected to guest, and the host CPU usage rises anyway, with
> or without this rule.

No, it is for suspending the usb bus, so qemu stops doing 1000 wakeups
per second when the usb tablet is idle.  Works only in case all devices
on the usb bus support it, but for the typical usb use case (-usbdevice
tablet for the abs ptr) this is the case.

> Now the question: should we remove this rule?

No.  We should fix whatever is broken.

>  Why it is needed
> to start with?

See above.

cheers,
  Gerd

Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?

[Michael Tokarev]

On 17.10.2012 12:56, Gerd Hoffmann wrote:
> On 10/17/12 10:41, Michael Tokarev wrote:
>> Hello.
>>
>> I noticed that "some" versions of linux guests shows quite
> 
> What is "some"?

I guess it is almost all modern distros.  Debian wheezy,
Ubuntu 12.4, current Fedora (17 I think) to name some.

>> As far as I can see, this rule is to reduce polling interrupt
>> frequency, but apparently it does not help: any usb device
>> connected to guest, and the host CPU usage rises anyway, with
>> or without this rule.
> 
> No, it is for suspending the usb bus, so qemu stops doing 1000 wakeups
> per second when the usb tablet is idle.  Works only in case all devices

This is very close to what I guessed, so I don't see why "No" ;)

> on the usb bus support it, but for the typical usb use case (-usbdevice
> tablet for the abs ptr) this is the case.

My command line:

  qemu-kvm -drive file=linux.img,if=virtio -usbdevice tablet

(plus a few other unrelated options).  That to say, there's nothing
more than just one usb tablet, it is exactly the case mentioned
above.

And indeed, the CPU utilization drops from - on my host - 12% to about
1.2% after a few secs of mouse being idle in the guest.  So I was
wrong here, and it actually works - it does what it was supposed to
do, it reduces CPU usage.

But the mouse is jumpy anyway.  I guess one can get used to this
behavour, given the tradeoff and that the behavour is not VERY annoying --
it is annoying, but just for a "bit", it feels like old mechanical
mouse with bad sensor or dirty ball when you can move the mouse but
cursor sometimes stays in place and sometimes moves, depending on
the surface and direction of the move... ;)

> No.  We should fix whatever is broken.

Is it _ever_ possible to fix this?

What happens when the (device, bus) is suspended?  Does host still
sends interrupts periodically (but with much lower frequency)?  Or
is it the bus/hub/device which should signal attention at some point?

Sorry I'm not even a novice in USB internals ;)

/mjt

Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?

[Michael Tokarev]

On 17.10.2012 13:15, Michael Tokarev wrote:
> But the mouse is jumpy anyway.  I guess one can get used to this
> behavour, given the tradeoff and that the behavour is not VERY annoying --
> it is annoying, but just for a "bit", it feels like old mechanical
> mouse with bad sensor or dirty ball when you can move the mouse but
> cursor sometimes stays in place and sometimes moves, depending on
> the surface and direction of the move... ;)

It is more like the case when your desktop system is swapping
heavily, so when you move mouse, it needs to swap-in parts of
X or clients which are supposed to react to mouse movement events,
so the movement is just delayed, not ignored altogether like
with bad/dirty ball.  And when you leave it alone, these parts
gets swapped out again, to be swapped in when you move it the
next time.

/mjt

Re: [Qemu-devel] udev 42-qemu-usb.rules considered harmful?

[Gerd Hoffmann]

  Hi,

> But the mouse is jumpy anyway.  I guess one can get used to this
> behavour, given the tradeoff and that the behavour is not VERY annoying --
> it is annoying, but just for a "bit", it feels like old mechanical
> mouse with bad sensor or dirty ball when you can move the mouse but
> cursor sometimes stays in place and sometimes moves, depending on
> the surface and direction of the move... ;)

How long are the delays for you?

> What happens when the (device, bus) is suspended?  Does host still
> sends interrupts periodically (but with much lower frequency)?  Or
> is it the bus/hub/device which should signal attention at some point?

UHCI raises an IRQ, guest restarts USB bus in response.  Which takes a
bit of time, so the first mouse event of an idle tablet takes a little
bit longer.  As far I know linux schedules the first poll a bit in the
future, so this could be where the delay comes from.

Do you also see delays with xhci? (-device nec-pci-xhci -device
usb-tablet) ?

cheers,
  Gerd