From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH 2/2] drm/i915: Prevent loading of uninitialized context garbage
Date: Wed, 21 Aug 2013 18:31:07 +0300 [thread overview]
Message-ID: <20130821153107.GG7159@intel.com> (raw)
In-Reply-To: <20130821134333.GD7159@intel.com>
On Wed, Aug 21, 2013 at 04:43:33PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 08, 2013 at 08:00:26PM +0100, Chris Wilson wrote:
> > The extended state bits are stored in the LCA register and affect all
> > updates to the LCA register - i.e. the state on the old context is saved
> > when SAVE_EX_STATE_EN is currently set in the old context address before
> > the update, and the new context is restored when RESTORE_EX_STATE_EN is
> > set in the new context address. This is irrespective of the
> > RESTORE_INHIBIT flag in the MI_SET_CONTEXT.
> >
> > Hence, upon initial loading the contents of the extended state is read
> > from uninitialised data. To workaround this, on first load we do a dummy
> > load without the mandatory RESTORE_EX_STATE_EN bit so that the real load
> > causes us to initialise the extended state of the context before it is
> > then loaded by the LCA update.
> >
> > v2: Split out the introduction of the variable length MI_SET_CONTEXT
> > command sequence.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Ben Widawsky <ben@bwidawsk.net>
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 8a7b61e..a57d49a 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -367,6 +367,8 @@ mi_set_context(struct intel_ring_buffer *ring,
> > case 5: len += 2;
> > break;
> > }
> > + if (!new_context->is_initialized)
> > + len += 2;
> >
> > ret = intel_ring_begin(ring, len);
> > if (ret)
> > @@ -382,6 +384,22 @@ mi_set_context(struct intel_ring_buffer *ring,
> > break;
> > }
> >
> > + if (!new_context->is_initialized) {
> > + /* The GPU tries to restore the extended state irrespective
> > + * of RestoreInhibit (since it is part of the LCA switch
> > + * itself rather than the MI_SET_CONTEXT command).
> > + * Since the initial contents may be garbage we do a dummy
> > + * load first then set the mandatory flag for any future
> > + * ring context switches.
> > + */
> > + intel_ring_emit(ring, MI_SET_CONTEXT);
> > + intel_ring_emit(ring,
> > + i915_gem_obj_ggtt_offset(new_context->obj) |
> > + MI_MM_SPACE_GTT |
> > + MI_SAVE_EXT_STATE_EN |
> > + hw_flags);
> > + }
>
> Hmm. Couldn't we just do this w/ one MI_SET_CONTEXT? Just drop the
> MI_RESTORE_EXT_STATE_EN flag if the context is not initialized. The
> MI_SAVE_EXT_STATE_EN will be saved in the CCID, so when we switch to
> another context the extended state will be saved. And for the next
> switch to this context we will set the MI_RESTORE_EXT_STATE_EN bit
> in MI_SET_CONTEXT so it should get restored.
>
> But I must admit BSpec is a bit confusing on the topic. It says the
> restore bit affects the switch to the context specified in the
> logical context address. I take that to mean that the effect of the
> restore bit is immediate. But BSpec also says that the bit is stored in
> CCID to control the subsequent switch to the same context. So does that
> actually mean that 'effective.restore_ext = CCID.restore_ext |
> MI_SET_CONTEXT.restore_ext'?
>
> Oh, but BSpec also says that both bits must be set when RS2 power state
> is enabled. I think that's the same as RC6, or is it? So I guess the
> hardware might consult these bits when entering/leaving RC6. So I suppose
> we really need to make sure both bits are always set in case we hit RC6.
> So based on that reasoning the patch would seem correct.
>
> I guess I'll give it an r-b regardless :)
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
I just noticed that on HSW these bits control the resource streamer
state save/restore. The spec says we should always set the RS
restore bit if we set the RS save bit. So maybe we need some
!IS_HASWELL checks in there...
>
> > +
> > intel_ring_emit(ring, MI_NOOP);
> > intel_ring_emit(ring, MI_SET_CONTEXT);
> > intel_ring_emit(ring, i915_gem_obj_ggtt_offset(new_context->obj) |
> > --
> > 1.8.4.rc1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2013-08-21 15:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 13:37 [PATCH] drm/i915: Prevent loading of uninitialized context garbage Chris Wilson
2013-08-08 17:12 ` Ben Widawsky
2013-08-08 19:00 ` [PATCH 1/2] drm/i915: Eliminate unrequired dwords for MI_SET_CONTEXT Chris Wilson
2013-08-08 19:00 ` [PATCH 2/2] drm/i915: Prevent loading of uninitialized context garbage Chris Wilson
2013-08-21 13:43 ` Ville Syrjälä
2013-08-21 15:31 ` Ville Syrjälä [this message]
2013-08-21 21:12 ` Daniel Vetter
2013-08-22 9:18 ` Abdiel Janulgue
2013-08-22 9:32 ` Ville Syrjälä
2013-08-09 9:41 ` [PATCH 1/2] drm/i915: Eliminate unrequired dwords for MI_SET_CONTEXT Daniel Vetter
2013-08-09 10:05 ` Chris Wilson
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=20130821153107.GG7159@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=ben@bwidawsk.net \
--cc=chris@chris-wilson.co.uk \
--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