public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: David Weinehall <david.weinehall@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 00/03] Preventing zero GPU virtual address allocation
Date: Thu, 21 May 2015 11:08:42 +0300	[thread overview]
Message-ID: <20150521080842.GF13974@boom> (raw)
In-Reply-To: <20150520161058.GG17761@nuc-i3427.alporthouse.com>

On Wed, May 20, 2015 at 05:10:58PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> > On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > > > This patch series (one patch each for libdrm, the kernel, and beignet)
> > > > > aims to provide a means to add a context-specific means to prevent
> > > > > a mapping to GPU virtual address zero.  This is needed at least by
> > > > > Beignet (possibly in other use-cases too, though I don't know of any
> > > > > other) to allow use of address zero to represent NULL.
> > > > 
> > > > Urm, you cannot allow absolute addressing period. What happens to the
> > > > object at 0 when the user reads from it or writes to it? You have to
> > > > have an object at 0 for the user's NULL pointer access.
> > > 
> > > I'll mollify that: outside of full-ppgtt where you need to share the VM.
> > 
> > The description is misleading, the new flag doesn't prevent anything from
> > getting mapped at 0 but only prevents any bo submitted through execbuf on
> > the given context from being bound at address 0. If that would happen
> > compute kernels using NULL checks for some things would fall over.

Any suggestion for a better description?

> That does not address the issue that *0 is an untrapped runtime bug that
> allows writing to other objects or reading from them.

Not exactly sure what you suggest here?


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

  reply	other threads:[~2015-05-21  8:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 13:54 [PATCH 00/03] Preventing zero GPU virtual address allocation David Weinehall
2015-05-20 14:00 ` [PATCH 01/03] drm/i915: add a context parameter to {en, dis}able zero address mapping David Weinehall
2015-05-28 14:39   ` Chris Wilson
2015-05-28 15:52     ` Daniel Vetter
2015-05-28 16:56       ` Chris Wilson
2015-05-29  8:18         ` David Weinehall
2015-05-20 14:01 ` [PATCH 02/03] libdrm: export context_{get, set}param and I915_CONTEXT_PARAM_NO_ZEROMAP David Weinehall
2015-05-20 14:02 ` [PATCH 03/03] beignet: set I915_CONTEXT_PARAM_NO_ZEROMAP when initializing context David Weinehall
2015-05-20 14:09 ` [PATCH 00/03] Preventing zero GPU virtual address allocation Chris Wilson
2015-05-20 14:14   ` Chris Wilson
2015-05-20 16:00     ` Daniel Vetter
2015-05-20 16:10       ` Chris Wilson
2015-05-21  8:08         ` David Weinehall [this message]
2015-05-21  8:43           ` Chris Wilson
2015-05-21  9:38             ` David Weinehall
2015-05-21  9:59               ` Chris Wilson
2015-05-21  9:44             ` Daniel Vetter
2015-05-21  9:50               ` Chris Wilson
2015-05-27  9:17                 ` David Weinehall
2015-06-05 14:13                   ` Dave Gordon
2015-05-21  7:59       ` David Weinehall
2015-05-27  7:54       ` Zou, Nanhai
2015-05-27 11:29         ` Daniel Vetter
2015-05-21  9:44 ` [PATCH i-g-t 4/3] tests/gem_ctx_param_basic: Expand ctx_param tests David Weinehall
2015-05-27 11:32   ` Daniel Vetter
2015-05-28 12:20     ` David Weinehall
2015-05-28 14:53     ` David Weinehall
2015-05-29  7:52       ` Daniel Vetter
2015-08-06 21:30         ` Daniel Vetter
2015-08-06 21:30           ` Daniel Vetter
2015-08-06 21:33           ` Jesse Barnes
2015-08-10 14:15             ` David Weinehall
2015-08-13 23:12               ` Jesse Barnes
2015-08-10 14:17           ` David Weinehall

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=20150521080842.GF13974@boom \
    --to=david.weinehall@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --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