From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9UyU-000065-BW for qemu-devel@nongnu.org; Thu, 17 Dec 2015 04:35:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9UyR-0003O6-MB for qemu-devel@nongnu.org; Thu, 17 Dec 2015 04:35:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9UyR-0003O0-G0 for qemu-devel@nongnu.org; Thu, 17 Dec 2015 04:35:47 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 0122437C38A for ; Thu, 17 Dec 2015 09:35:46 +0000 (UTC) References: <1450273165-2367-1-git-send-email-lvivier@redhat.com> <1450273165-2367-3-git-send-email-lvivier@redhat.com> From: Thomas Huth Message-ID: <567281EF.4000304@redhat.com> Date: Thu, 17 Dec 2015 10:35:43 +0100 MIME-Version: 1.0 In-Reply-To: <1450273165-2367-3-git-send-email-lvivier@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] ohci: clear pending SOF on suspend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier , qemu-devel@nongnu.org Cc: Gerd Hoffmann On 16/12/15 14:39, Laurent Vivier wrote: > On overcommitted CPU, kernel can be so slow that an interrupt can > be triggered by the device whereas the driver is not ready to receive > it. This drives us into an infinite loop. > > On suspend, if a SOF interrupt is raised between the stop of the > device processing and the change of the device internal state to > OHCI_USB_SUSPEND (QEMU stops SOF timer on this state change), this > interrupt is never acknowledged. > > This patch clears pending SOF interrupt on OHCI_USB_SUSPEND setting. > > Some details: > > - ohci_irq(): the OHCI interrupt handler, acknowledges the SOF IRQ > only if the state of the driver (rh_state) is OHCI_STATE_RUNNING. > So if this interrupt happens and the driver is not in this state, > the function is called again and again, moving the system to a > CPU starvation. > > - ohci_rh_suspend(): the function stop the operation and acknowledge > pending interrupts (but doesn't disable it). Later in the function, > the device is moved to OHCI_SUSPEND_STATE, and the driver to > OHCI_RH_SUSPENDED. If between the moment when the interrupt is > acknowledged and the moment when the device is suspended a new > interrupt is raised, it will be never acknowledged because the > driver is now not in OHCI_RH_RUNNING state. > > Signed-off-by: Laurent Vivier > --- > hw/usb/hcd-ohci.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/usb/hcd-ohci.c b/hw/usb/hcd-ohci.c > index 5f15ebb..b5a4e39 100644 > --- a/hw/usb/hcd-ohci.c > +++ b/hw/usb/hcd-ohci.c > @@ -1438,6 +1438,9 @@ static void ohci_set_ctl(OHCIState *ohci, uint32_t val) > break; > case OHCI_USB_SUSPEND: > ohci_bus_stop(ohci); > + /* clear pending SF otherwise driver loops in ohci_irq() */ May I suggest to talk about "Linux driver" instead of only "driver" here? ... QEMU also supports other guests, so the context might not be clear otherwise. > + ohci->intr_status &= ~OHCI_INTR_SF; > + ohci_intr_update(ohci); > break; > case OHCI_USB_RESUME: > trace_usb_ohci_resume(ohci->name); Apart from that nit in the comment, patch looks sane to me. Reviewed-by: Thomas Huth