linux-kernel - [PATCH 3.2 30/74] drm/i915: Disable MSI for all pre-gen5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <lsq.1507552234.981201681@decadent.org.uk>
Date:   Mon, 09 Oct 2017 13:30:34 +0100
From:   Ben Hutchings <ben@...adent.org.uk>
To:     linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC:     akpm@...ux-foundation.org, "Jani Nikula" <jani.nikula@...el.com>,
        "Diego Viola" <diego.viola@...il.com>,
        "Ville Syrjälä" 
        <ville.syrjala@...ux.intel.com>,
        "Daniel Vetter" <daniel.vetter@...ll.ch>
Subject: [PATCH 3.2 30/74] drm/i915: Disable MSI for all pre-gen5

3.2.94-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Ville Syrjälä <ville.syrjala@...ux.intel.com>

commit ce3f7163e4ce8fd583dcb36b6ee6b81fd1b419ae upstream.

We have pretty clear evidence that MSIs are getting lost on g4x and
somehow the interrupt logic doesn't seem to recover from that state
even if we try hard to clear the IIR.

Disabling IER around the normal IIR clearing in the irq handler isn't
sufficient to avoid this, so the problem really seems to be further
up the interrupt chain. This should guarantee that there's always
an edge if any IIR bits are set after the interrupt handler is done,
which should normally guarantee that the CPU interrupt is generated.
That approach seems to work perfectly on VLV/CHV, but apparently
not on g4x.

MSI is documented to be broken on 965gm at least. The chipset spec
says MSI is defeatured because interrupts can be delayed or lost,
which fits well with what we're seeing on g4x. Previously we've
already disabled GMBUS interrupts on g4x because somehow GMBUS
manages to raise legacy interrupts even when MSI is enabled.

Since there's such widespread MSI breakahge all over in the pre-gen5
land let's just give up on MSI on these platforms.

Seqno reporting might be negatively affected by this since the legcy
interrupts aren't guaranteed to be ordered with the seqno writes,
whereas MSI interrupts may be? But an occasioanlly missed seqno
seems like a small price to pay for generally working interrupts.

Cc: Diego Viola <diego.viola@...il.com>
Tested-by: Diego Viola <diego.viola@...il.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261
Signed-off-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@...ll.ch>
(cherry picked from commit e38c2da01f76cca82b59ca612529b81df82a7cc7)
Signed-off-by: Jani Nikula <jani.nikula@...el.com>
[bwh: Backported to 3.2:
 - Open-code INTEL_GEN()
 - Adjust filename, context]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
 drivers/gpu/drm/i915/i915_dma.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2059,10 +2059,12 @@ int i915_driver_load(struct drm_device *
 	 * and the registers being closely associated.
 	 *
 	 * According to chipset errata, on the 965GM, MSI interrupts may
-	 * be lost or delayed, but we use them anyways to avoid
-	 * stuck interrupts on some machines.
+	 * be lost or delayed, and was defeatured. MSI interrupts seem to
+	 * get lost on g4x as well, and interrupt delivery seems to stay
+	 * properly dead afterwards. So we'll just disable them for all
+	 * pre-gen5 chipsets.
 	 */
-	if (!IS_I945G(dev) && !IS_I945GM(dev))
+	if (INTEL_INFO(dev)->gen >= 5)
 		pci_enable_msi(dev->pdev);

 	spin_lock_init(&dev_priv->gt_lock);