From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 00/13] Gen7 batch buffer command parser
Date: Tue, 25 Mar 2014 20:53:42 +0100
Message-ID: <20140325195342.GN26878@phenom.ffwll.local>
References: <1392747357-25703-1-git-send-email-bradley.d.volkin@intel.com>
 <87y5050w3q.fsf@intel.com>
 <20140325131536.GC26878@phenom.ffwll.local>
 <20140325194637.GA4292@bdvolkin-ubuntu-desktop>
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-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52])
 by gabe.freedesktop.org (Postfix) with ESMTP id DF2DA6E3D2
 for <intel-gfx@lists.freedesktop.org>; Tue, 25 Mar 2014 12:53:48 -0700 (PDT)
Received: by mail-ee0-f52.google.com with SMTP id e49so835925eek.25
 for <intel-gfx@lists.freedesktop.org>; Tue, 25 Mar 2014 12:53:46 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20140325194637.GA4292@bdvolkin-ubuntu-desktop>
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: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Tue, Mar 25, 2014 at 12:46:37PM -0700, Volkin, Bradley D wrote:
> On Tue, Mar 25, 2014 at 06:15:36AM -0700, Daniel Vetter wrote:
> > - Secure batch dispatch is still fubar.
> 
> I'm not sure that this will still impact us once we implement the batch copy
> step. I was only using the secure dispatch stuff because it was a convenient
> way to get the batch into GGTT. But with the copy step, we could just have
> separate code to do that.

The problem isn't copying or allocating the bo, the issue is running it
with
a) the hw checker disabled
b) not mapped into any ppgtt so hidden from all (unchecked) access and
c) otherwise working like a normal batch.

For that we need to employ the secure batch dispatch code in the execbuf
code. Atm b) is broken for aliasing ppgtt and c) is broken for full ppgtt.
So a bit of blockers for us. But at least broken b) with aliasing ppgtt is
kinda a regression, which means I'll get around to it soonish (before
3.15-rc1 at least).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch