All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Woodhouse <David.Woodhouse@intel.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	miku@iki.fi, beignet@lists.freedesktop.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC PATCH 2/3] drm/i915: IOMMU based SVM implementation v16
Date: Thu, 12 Jan 2017 17:48:49 +0200	[thread overview]
Message-ID: <87lgugcm8u.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20170109211808.GC19067@nuc-i3427.alporthouse.com>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> On Mon, Jan 09, 2017 at 06:52:53PM +0200, Mika Kuoppala wrote:
>> +static int i915_gem_context_enable_svm(struct i915_gem_context *ctx)
>> +{
>> +	int ret;
>> +
>> +	if (!HAS_SVM(ctx->i915))
>> +		return -ENODEV;
>
> How does legacy execbuf work with an svm context? It will write the
> ppgtt, but those are no longer read by the GPU. So it will generate
> faults at random addresses. Am I right in thinking we need to EINVAL if
> using execbuf + context_is_svm?

Yes without further experiments, it is best to block the legacy path
with -EINVAL. I will add this.

I guess with some tweaking the legacy interface could be made to work,
but it would need is_svm_context() checks in rather many places
in the execbuffer path to avoid relocations/pins.

-Mika

> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-01-12 15:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09 16:52 [RFC PATCH 0/3] SVM for kbl Mika Kuoppala
2017-01-09 16:52 ` [RFC PATCH 1/3] drm/i915: Create context desc template when context is created Mika Kuoppala
2017-01-09 21:22   ` Chris Wilson
2017-01-09 16:52 ` [RFC PATCH 2/3] drm/i915: IOMMU based SVM implementation v16 Mika Kuoppala
2017-01-09 21:18   ` Chris Wilson
2017-01-12 15:48     ` Mika Kuoppala [this message]
2017-01-12 16:03       ` Chris Wilson
2017-01-12 16:10         ` Jesse Barnes
2017-01-09 16:52 ` [RFC PATCH 3/3] drm/i915: add SVM execbuf ioctl v13 Mika Kuoppala
2017-01-09 21:09   ` Chris Wilson
2017-02-07 12:11     ` Mika Kuoppala
2017-02-07 12:23       ` Chris Wilson
2017-01-09 17:54 ` ✗ Fi.CI.BAT: failure for SVM for kbl Patchwork

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=87lgugcm8u.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=David.Woodhouse@intel.com \
    --cc=beignet@lists.freedesktop.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dwmw2@infradead.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=miku@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.