From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH] drm/i915: Add OACONTROL to the command parser register whitelist. Date: Wed, 26 Mar 2014 10:37:44 -0700 Message-ID: <53331068.7090007@whitecape.org> References: <1395813123-2027-1-git-send-email-kenneth@whitecape.org> <20140326062123.GO26878@phenom.ffwll.local> <20140326160358.GA11367@bdvolkin-ubuntu-desktop> <20140326163820.GV26878@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2082869821==" Return-path: Received: from homiemail-a38.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by gabe.freedesktop.org (Postfix) with ESMTP id 59CC76E3AD for ; Wed, 26 Mar 2014 10:37:24 -0700 (PDT) In-Reply-To: <20140326163820.GV26878@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , "Volkin, Bradley D" Cc: "intel-gfx@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============2082869821== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RERWHgeWpjq0Qj3vNkTBNq9AV6l66beX7" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RERWHgeWpjq0Qj3vNkTBNq9AV6l66beX7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 >>> >>> Thanks a lot for quickly tracking this down. Now when we've talked ab= out >>> OA a little while ago we concluded that mesa should clear OACONTROL a= gain >>> before the batch ends to make sure that userspace can't unduly observ= e >>> other processes. So I think it'd be worth to keep track of this with = a >>> flag (set when OACONTROL is !=3D 0 and reset when the batch loads 0).= Also >>> we need to make sure that userspace sets the right OACONTROL modes (n= ot >>> 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. T= hat >> might require separate whitelists for MI_LOAD_REGISTER_IMM/MEM. Not th= e 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 addit= ional >> registers or different uses of any registers. >=20 > Afaik there's no other register we want to reset again. I think all oth= er > 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. I don't really buy the snooping problem, though...just because I leave OACONTROL set doesn't mean I'll get useful data. Another context might clobber it, and empirically the numbers seem to reset across RC6 anyway. So in actuality, they're likely to get bogus data. Even if they did somehow miraculously get decent values, it basically gives information akin to 'top', which is unprivileged on every system I've ever used. The other alternative is to have the kernel write OACONTROL to 0 after any batch that alters it. Then the kernel wouldn't need to care what userspace does with it. (I think Daniel preferred having userspace reset it, though.) --Ken --RERWHgeWpjq0Qj3vNkTBNq9AV6l66beX7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTMxBwAAoJEFtb2gcdScw4XMcP/jrmoXUxMe/N3bv6w6ZHJaF1 ShBw3O6Y+MtOrlczcfV39ij7BBSQ4ri/QSYM/+DHLnXAFgEVdKmfUaf4BtwAaHcD 06NtiVwIb3bDiBz6p9WxBFa+pEm8lAYOxCa2drWYYby+cvwJ7fAbp/lr/2eAfOyj m6jXBT6m+EIZwQ35K19UZFosLvrmHpFbVwvls16VuQVokJQgRsqce6/nhWxyZGjg XYBqp4BGP0/uPTHAhHfPGuuMfA+WAsNr2h2k+H3wOuCR/Kpnc2XLPE0aV2Cr5pje /BSXxM+QJmZfIb8AU8WaXLJKczajiRQE9F7b3WXRauIWzWlRAGiI07qd/0YMxth1 jYEZsLYXj8hDOQJNpD/7A85DESptJd0MBoqfuyYW0LFZbamKhYc58Pv6o0zHlIFS HOqTrPXBstCqIlWoFgXyJmR6XO5IJJ/ED27BPLauqFoXp300rI5Q9Te2SNVxo6aD Zy7QFdF9mTlKGkvgv2bqaUrKfzr97+qzZrPpZJKmQv15L276JLmfMlZ3e7l5wAjw 3vr6To3hH/MioI2tqH8AyKANzCJ4VplzzFE5VTO+AefW0xaKjtMhhhppAskO41Ix o2zGir9oabzAtbHSlIx4Wyu+Alcr1LfYhwPs4fwnQX8sGEaOo6mw5ebi6J08rM8W nufQwnwoTYHcjmEffu77 =MT3b -----END PGP SIGNATURE----- --RERWHgeWpjq0Qj3vNkTBNq9AV6l66beX7-- --===============2082869821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============2082869821==--