Hi, On Mon, Oct 08, 2012 at 05:03:24PM +0200, Hans de Goede wrote: > On 10/08/2012 04:49 PM, Johannes Stezenbach wrote: > >On Mon, Oct 08, 2012 at 03:51:08PM +0200, Hans de Goede wrote: > >>the real problem is the > >>"ehci warning: guest updated active QH" message, which most likely indicates > >>that the guest has hit the doorbell (IAAD) in the EHCI controller, and then > >>has not gotten an IAA interrupt within > >>a certain amount of time triggering its IAAD watchdog (some real EHCI > >>hardware is broken wrt delivering IAA interrupt) causing us to not see > >>an unlinked qh as unlinked, and then later on triggering the > >>"warning: guest updated active QH" message. > >> > >>This is unavoidable when we get too large latencies, the ehci hardware > >>simple was not designed to be virtualized, anything but actually. > > > >OK, thanks for this explanation. > >I haven't much clue about qemu but isn't the issue that qemu > >delivers timer irqs to the guest (for EHCI_HRTIMER_IAA_WATCHDOG) while > >failing to handle the IAAD -> IAA interrupt generation? > >(via qemu_bh_schedule -> ehci_advance_async_state -> ehci_raise_irq, > >why does ehci_raise_irq() not call ehci_update_irq() for USBSTS_IAA?) > > We need to throttle the interrupt generation inside ehci both per > the spec, and because otherwise we may trigger: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=361aabf395e4a23cf554cf4ec0c0c6963b8beb01 > > Which is present in all but the very latest linux kernels.
Not nice :-( > We do our best to make the whole usb-redir code and ehci emulation as > proof as possible against latency spikes, and some of the patches > from my latest patchset may help there, but in the end, esp. for > isoc devices, the code will always be sensitive to too large latencies. OK, I read up on the EHCI interrupt threshold and found how ehci_frame_timer() calls ehci_commit_irq(). I agree it is hard to fix. I wonder if it would be sufficient if qemu would guarantee ehci_frame_timer() runs before sending the timer irq that triggers the IAA timeout, but I guess it depends on what the guest processes first. I also wonder if this is not a generic problem for all emulated hw if the driver uses some timeout? Thanks Johannes
