From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerome Glisse Subject: Re: [PATCH v2] drm: enable render-nodes by default Date: Thu, 20 Mar 2014 11:35:47 -0400 Message-ID: <20140320153545.GC2020@gmail.com> References: <1395074636-32337-1-git-send-email-dh.herrmann@gmail.com> <532A8E07.5000208@shipmail.org> <532AAB78.6010500@vmware.com> <532AB481.40309@vmware.com> <532AC2C2.5030606@vmware.com> <20140320143600.GA2020@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by gabe.freedesktop.org (Postfix) with ESMTP id 108B36E0EB for ; Thu, 20 Mar 2014 08:35:51 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id e89so3087806qgf.5 for ; Thu, 20 Mar 2014 08:35:51 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ilia Mirkin Cc: Daniel Vetter , Thomas Hellstrom , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On Thu, Mar 20, 2014 at 10:44:10AM -0400, Ilia Mirkin wrote: > On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse wrot= e: > > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote: > >> On 03/20/2014 10:43 AM, David Herrmann wrote: > >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom > >> > wrote: > >> > Given that the legacy node is always around and _always_ has these > >> > races, why should we prevent render-nodes from appearing just because > >> > the _driver_ is racy? I mean, there is no gain in that.. if it opens= a > >> > new race, as you assumed, then yes, we should avoid it. But at least > >> > for all drivers supporting render-nodes so far, they either are > >> > entirely safe or the just described races exist on both nodes. > >> > >> My suggestion is actually not to prevent render nodes from appearing, > >> but rather that we should restrict them to drivers with command stream > >> verification and / or per process virtual memory, and I also think we > >> should plug the above races on legacy nodes. That way legacy nodes wou= ld > >> use the old "master owns it all" model, while render nodes could allow > >> multiple users at the same time. > > > > FYI both radeon and nouveau (last time i check) can not be abuse to acc= ess > > random VRAM or buffer bind by another process (except if the buffer is = share > > of course). > = > I'm not aware of any restrictions in nouveau that would prevent you > from accessing any vram... there are a number of copy engines > accessible that would allow you to copy one region to another, and I'm > not aware of code to validate pushbuf contents (it would have to parse > the pushbuf and know which methods store source/destination > addresses). You could probably get creative and use that to overwrite > the MMU tables, to then gain the ability to read/write any part of > system memory... but perhaps the engines won't allow you to do that, > not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not > sure.) > = > -ilia Well i obviously have not look at that in long time, but if the nouveau API can be abuse than i consider this a broken by design. I know command checking is painfull and CPU intensive but we have done it in radeon for a reason. Cheers, J=E9r=F4me