qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 8/8] usb-hid: Allow connecting to a USB-2 device


From: Hans de Goede
Subject: Re: [Qemu-devel] [PATCH 8/8] usb-hid: Allow connecting to a USB-2 device
Date: Mon, 12 Nov 2012 12:19:48 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

Hi,

On 11/08/2012 04:36 PM, Gerd Hoffmann wrote:
On 11/06/12 15:08, Hans de Goede wrote:
Our ehci code has is capable of significantly lowering the wakeup rate
for the hcd emulation while the device is idle. It is possible to add
similar code ot the uhci emulation, but that simply is not there atm,
and there is no reason why a (virtual) usb device can not be a USB-2 device.

We should probably add usb-tablet2 (+friends) devices as this is a
guest-visible change.  We could also try tricks with properties but I
guess separate devices are easier.

A quick status update on this patchset.

a) I promised to resend it without this patch Friday afternoon at kvm-forum,
which I went to do directly after saying goodbye, but when I unsuspended my
laptop it broke... (looks like the cable between the motherboard and screen
has a loose contact), so it got delayed a bit.

b) While working on fixing all the comments on the set yesterday to send a v2,
I realized at the very last moment that handling interrupts packet async,
rather then by nakking them, causes problems with migration, as the following
can happen:

1) hcd submits a packet to device, device returns USB_RET_ASYNC
2) device gets some data, fills the packet, calls complete() on it
3) For ehci complete() calls a bh, which immediately walks the async
   schedule, but if not enough time has passed since the last bh, to
   process periodic frames, or if the interrupt endpoint has an interval
   of more then 1 ms, and this periodic frame it is not scheduled, the
   completion will not get written back to guest memory!
4) If we now migrate, the completion never gets written back to guest
   memory and the interrupt packet is effectively lost

Notice that the same can happen with non async interrupt packets on the uhci
code... I was planning on modifying that to be more like the ehci code anyways
to lower the CPU-load (amount of wakeups), but that will not necessarily fix
this, so this needs some more thinking.

I hope to have a v2 of the wakeup reduction for interrupt endpoints patchset
by the end of the day ...

Regards,

Hans



reply via email to

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