From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLFw9-0002hC-Gg for qemu-devel@nongnu.org; Mon, 08 Oct 2012 12:12:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLFw4-0007MB-Lq for qemu-devel@nongnu.org; Mon, 08 Oct 2012 12:12:09 -0400 Received: from bar.sig21.net ([80.81.252.164]:33034) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLFw4-0007Lt-FV for qemu-devel@nongnu.org; Mon, 08 Oct 2012 12:12:04 -0400 Date: Mon, 8 Oct 2012 18:11:55 +0200 From: Johannes Stezenbach Message-ID: <20121008161155.GA618@sig21.net> References: <3321480.8UDes0xfFC@segfault.sh0n.net> <50606FDF.3070408@redhat.com> <10559125.MRDnL6POYS@segfault.sh0n.net> <2581372.ig9fx04ALR@segfault.sh0n.net> <5072B8A0.9060700@redhat.com> <20121008130125.GA3622@sig21.net> <5072DA4C.8050708@redhat.com> <20121008144909.GA31171@sig21.net> <5072EB3C.70004@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5072EB3C.70004@redhat.com> Subject: Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: Shawn Starr , qemu-devel@nongnu.org, gerd@kraxel.org 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