From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm/i915: Add OACONTROL to the command parser register whitelist. Date: Wed, 26 Mar 2014 17:38:20 +0100 Message-ID: <20140326163820.GV26878@phenom.ffwll.local> References: <1395813123-2027-1-git-send-email-kenneth@whitecape.org> <20140326062123.GO26878@phenom.ffwll.local> <20140326160358.GA11367@bdvolkin-ubuntu-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by gabe.freedesktop.org (Postfix) with ESMTP id AE09A6E6E5 for ; Wed, 26 Mar 2014 09:38:25 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so1878305eek.13 for ; Wed, 26 Mar 2014 09:38:24 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140326160358.GA11367@bdvolkin-ubuntu-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Volkin, Bradley D" Cc: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org On Wed, Mar 26, 2014 at 09:03:58AM -0700, Volkin, Bradley D wrote: > On Tue, Mar 25, 2014 at 11:21:23PM -0700, Daniel Vetter wrote: > > On Tue, Mar 25, 2014 at 10:52:03PM -0700, Kenneth Graunke wrote: > > > Mesa needs to be able to write OACONTROL in order to expose the > > > Observability Architecture's performance counters via OpenGL. > > > > > > Signed-off-by: Kenneth Graunke > > > > Thanks a lot for quickly tracking this down. Now when we've talked about > > OA a little while ago we concluded that mesa should clear OACONTROL again > > before the batch ends to make sure that userspace can't unduly observe > > other processes. So I think it'd be worth to keep track of this with a > > flag (set when OACONTROL is != 0 and reset when the batch loads 0). Also > > we need to make sure that userspace sets the right OACONTROL modes (not > > the one which streams into a global gtt buffer essentially). So some > > additional work required. > > Ok, I'll look into this. And apologies for not catching it myself. > > If we have to do additional checks on fields within the registers then I > suppose we'll need to limit those registers to MI_LOAD_REGISTER_IMM. That > might require separate whitelists for MI_LOAD_REGISTER_IMM/MEM. Not the end > of the world, but certainly some additional complexity. > > For the resetting check, are there other registers in the current list that > should have this tracking? If so, is 0 the reset value in all cases? > > Let me know if there is anything in the works that would require additional > registers or different uses of any registers. Afaik there's no other register we want to reset again. I think all other register we might want to clear are already part of hw contexts, so no chance to leak stuff (e.g. the streamout registers and a end-of-pipe counters). Ken might know of something I've missed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch