Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting

[Johannes Stezenbach <js@sig21.net>]

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