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

[Hans de Goede <hdegoede@redhat.com>]

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