public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Kenneth Graunke <kenneth@whitecape.org>
To: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Add OACONTROL to the command parser register whitelist.
Date: Wed, 26 Mar 2014 15:34:35 -0700	[thread overview]
Message-ID: <533355FB.4010706@whitecape.org> (raw)
In-Reply-To: <20140326182605.GA28133@bdvolkin-ubuntu-desktop>


[-- Attachment #1.1: Type: text/plain, Size: 2663 bytes --]

On 03/26/2014 11:26 AM, Volkin, Bradley D wrote:
> On Wed, Mar 26, 2014 at 10:37:44AM -0700, Kenneth Graunke wrote:
>> On 03/26/2014 09:38 AM, Daniel Vetter wrote:
>>> 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 <kenneth@whitecape.org>
>>>>>
>>>>> 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
>>
>> Right, I think it's just OACONTROL.  I don't think there's a need to
>> filter particular values.
> 
> Sorry, I don't follow you here. Can you clarify what you mean r.e. filtering?

Oh, I meant I don't think we need to do additional checks on "fields
within the registers" (to quote your email) or restrict the values we
can write to the registers.  Just the ability to write the whole
register to any arbitrary value should be sufficient.

Thanks Brad!

--Ken


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2014-03-26 22:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26  5:52 [PATCH] drm/i915: Add OACONTROL to the command parser register whitelist Kenneth Graunke
2014-03-26  6:21 ` Daniel Vetter
2014-03-26 16:03   ` Volkin, Bradley D
2014-03-26 16:38     ` Daniel Vetter
2014-03-26 17:37       ` Kenneth Graunke
2014-03-26 18:26         ` Volkin, Bradley D
2014-03-26 21:48           ` Daniel Vetter
2014-03-26 22:34           ` Kenneth Graunke [this message]
2014-03-27  7:57           ` Daniel Vetter
2014-03-27 15:57             ` Volkin, Bradley D
2014-03-27 20:16               ` Daniel Vetter
2014-03-27 21:34                 ` Kenneth Graunke
2014-03-27 22:44                   ` Daniel Vetter
2014-03-27 23:22                     ` Kenneth Graunke
2014-05-16 19:05                       ` Jesse Barnes
2014-05-16 19:20                         ` Chris Wilson
2014-05-16 19:34                           ` Jesse Barnes
2014-05-16 19:49                             ` Chris Wilson
2014-05-16 20:12                               ` Jesse Barnes
2014-05-16 19:53                             ` Jesse Barnes
2014-05-16 20:12                               ` Volkin, Bradley D
2014-05-16 20:14                                 ` Jesse Barnes
2014-03-27 23:42                 ` Volkin, Bradley D
2014-03-28  7:36                   ` Chris Wilson
2014-03-26  9:57 ` Jani Nikula
2014-03-26 10:41   ` [PATCH v2] " Kenneth Graunke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=533355FB.4010706@whitecape.org \
    --to=kenneth@whitecape.org \
    --cc=bradley.d.volkin@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox