From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH] drm/i915: Do not access stolen memory
 directly by the CPU, even for error capture
Date: Sun, 20 Jul 2014 11:59:31 -0700
Message-ID: <20140720185931.GA10173@bwidawsk.net>
References: <1392232720-28711-1-git-send-email-chris@chris-wilson.co.uk>
 <20140424214748.GA23141@bwidawsk.net>
 <20140715141508.GW15237@phenom.ffwll.local>
 <20140716033033.GB17077@bwidawsk.net>
 <20140720082955.GA15008@nuc-i3427.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mail.bwidawsk.net (bwidawsk.net [166.78.191.112])
 by gabe.freedesktop.org (Postfix) with ESMTP id 0C0A26E02D
 for <intel-gfx@lists.freedesktop.org>; Sun, 20 Jul 2014 11:59:45 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20140720082955.GA15008@nuc-i3427.alporthouse.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Chris Wilson <chris@chris-wilson.co.uk>, Daniel Vetter <daniel@ffwll.ch>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Sun, Jul 20, 2014 at 09:29:55AM +0100, Chris Wilson wrote:
> On Tue, Jul 15, 2014 at 08:30:33PM -0700, Ben Widawsky wrote:
> > On Tue, Jul 15, 2014 at 04:15:08PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 24, 2014 at 02:47:48PM -0700, Ben Widawsky wrote:
> > > > On Wed, Feb 12, 2014 at 07:18:40PM +0000, Chris Wilson wrote:
> > > > > For stolen pages, since it is verboten to access them directly on many
> > > > > architectures, we have to read them through the GTT aperture. If they
> > > > > are not accessible through the aperture, then we have to abort.
> > > > > 
> > > > > This was complicated by
> > > > > 
> > > > > commit 8b6124a633d8095b0c8364f585edff9c59568a96
> > > > > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Date:   Thu Jan 30 14:38:16 2014 +0000
> > > > > 
> > > > >     drm/i915: Don't access snooped pages through the GTT (even for error capture)
> > > > > 
> > > > > and the desire to use stolen memory for ringbuffers, contexts and
> > > > > batches in the future.
> > > > 
> > > > I am somewhat unclear as to whether we want to prefer the aperture for
> > > > reading back objects which may be mapped in multiple address spaces.
> > 
> > Can we just ioremap the physical address (at least for error capture)?
> 
> Do you want to hard hang the machine?
> -Chris
> 

What's the latest GEN you can hang the machine with? This is
ioremap_nocache we're talking about, right? I will try it on BDW
tomorrow.

I can't imagine anything but snoop cycles hanging the machine...

-- 
Ben Widawsky, Intel Open Source Technology Center