From nobody Thu May 2 23:11:55 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1486104777746805.9462706390711; Thu, 2 Feb 2017 22:52:57 -0800 (PST) Received: from localhost ([::1]:60447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZXjo-0006Xw-Dx for importer@patchew.org; Fri, 03 Feb 2017 01:52:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZXiv-0006CO-Sk for qemu-devel@nongnu.org; Fri, 03 Feb 2017 01:51:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZXis-0007Lt-Ry for qemu-devel@nongnu.org; Fri, 03 Feb 2017 01:51:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36094) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cZXis-0007Lf-JS for qemu-devel@nongnu.org; Fri, 03 Feb 2017 01:51:54 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6E4624E4D1; Fri, 3 Feb 2017 06:51:54 +0000 (UTC) Received: from nilsson.home.kraxel.org (ovpn-116-78.ams2.redhat.com [10.36.116.78]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v136prkx004388; Fri, 3 Feb 2017 01:51:53 -0500 Received: by nilsson.home.kraxel.org (Postfix, from userid 500) id 5197B80761; Fri, 3 Feb 2017 07:51:51 +0100 (CET) From: Gerd Hoffmann To: qemu-devel@nongnu.org Date: Fri, 3 Feb 2017 07:51:45 +0100 Message-Id: <1486104705-13761-1-git-send-email-kraxel@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 03 Feb 2017 06:51:54 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH] xhci: fix event queue IRQ handling X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 1373228@bugs.launchpad.net, Gerd Hoffmann , M.Cerveny@computer.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The qemu xhci emulation doesn't handle the ERDP_EHB flag correctly. When the host adapter queues a new event the ERDP_EHB flag is set. The flag is cleared (via w1c) by the guest when it updates the ERDP (event ring dequeue pointer) register to notify the host adapter which events it has fetched. An IRQ must raised in case the ERDP_EHB flag flips from clear to set. If the flag is set already (which implies there are events queued up which are not yet processed by the guest) xhci must *not* raise a IRQ. Qemu got that wrong and raised an IRQ on every event, thereby generating suspious interrupts in case we've queued events faster than the guest processed them. This patch fixes that. With that change in place we also have to check ERDP updates, to see whenever the guest has fetched all queued events. In case there are still pending events set ERDP_EHB and raise an IRQ again, to make sure the events don't linger unseen forever. The linux kernel driver and the microsoft windows driver (shipped with win8+) can deal with the suspious interrupts without problems. The renesas windows driver (v2.1.39) which can be used on older windows versions is quite upset though. It does suspious ERDP updates now and then (not every time, seems we must hit a race window for this to happen), which in turn makes the qemu xhci emulation think the event ring is full. Things go south from here ... tl;dr: This is the "fix xhci on win7" patch. Cc: M.Cerveny@computer.org Cc: 1373228@bugs.launchpad.net Signed-off-by: Gerd Hoffmann --- hw/usb/hcd-xhci.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c index df75907..4f05747 100644 --- a/hw/usb/hcd-xhci.c +++ b/hw/usb/hcd-xhci.c @@ -789,11 +789,15 @@ static void xhci_msix_update(XHCIState *xhci, int v) static void xhci_intr_raise(XHCIState *xhci, int v) { PCIDevice *pci_dev =3D PCI_DEVICE(xhci); + bool pending =3D (xhci->intr[v].erdp_low & ERDP_EHB); =20 xhci->intr[v].erdp_low |=3D ERDP_EHB; xhci->intr[v].iman |=3D IMAN_IP; xhci->usbsts |=3D USBSTS_EINT; =20 + if (pending) { + return; + } if (!(xhci->intr[v].iman & IMAN_IE)) { return; } @@ -3352,6 +3356,15 @@ static void xhci_runtime_write(void *ptr, hwaddr reg, intr->erdp_low &=3D ~ERDP_EHB; } intr->erdp_low =3D (val & ~ERDP_EHB) | (intr->erdp_low & ERDP_EHB); + if (val & ERDP_EHB) { + dma_addr_t erdp =3D xhci_addr64(intr->erdp_low, intr->erdp_hig= h); + unsigned int dp_idx =3D (erdp - intr->er_start) / TRB_SIZE; + if (erdp >=3D intr->er_start && + erdp < (intr->er_start + TRB_SIZE * intr->er_size) && + dp_idx !=3D intr->er_ep_idx) { + xhci_intr_raise(xhci, v); + } + } break; case 0x1c: /* ERDP high */ intr->erdp_high =3D val; --=20 1.8.3.1