[Intel-gfx] [PATCH] drm/i915/ehl: unconditionally flush the pages on acquire
Daniel Vetter
daniel at ffwll.ch
Fri Jul 9 16:57:35 UTC 2021
On Fri, Jul 9, 2021 at 6:35 PM Matthew Auld
<matthew.william.auld at gmail.com> wrote:
>
> On Fri, 9 Jul 2021 at 17:13, Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > On Fri, Jul 9, 2021 at 5:19 PM Matthew Auld <matthew.auld at intel.com> wrote:
> > >
> > > EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
> > > possible for userspace to bypass the GTT caching bits set by the kernel,
> > > as per the given object cache_level. This is troublesome since the heavy
> > > flush we apply when first acquiring the pages is skipped if the kernel
> > > thinks the object is coherent with the GPU. As a result it might be
> > > possible to bypass the cache and read the contents of the page directly,
> > > which could be stale data. If it's just a case of userspace shooting
> > > themselves in the foot then so be it, but since i915 takes the stance of
> > > always zeroing memory before handing it to userspace, we need to prevent
> > > this.
> > >
> > > BSpec: 34007
> > > References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
> > > Signed-off-by: Matthew Auld <matthew.auld at intel.com>
> > > Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay at intel.com>
> > > Cc: Francisco Jerez <francisco.jerez.plata at intel.com>
> > > Cc: Lucas De Marchi <lucas.demarchi at intel.com>
> > > Cc: Jon Bloomfield <jon.bloomfield at intel.com>
> > > Cc: Chris Wilson <chris.p.wilson at intel.com>
> > > Cc: Matt Roper <matthew.d.roper at intel.com>
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 29 +++++++++++++++++++++--
> > > 1 file changed, 27 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > > index 6a04cce188fc..7e9ec68cce9e 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > > @@ -298,11 +298,12 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
> > >
> > > void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_table *pages)
> > > {
> > > + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> > > struct sgt_iter sgt_iter;
> > > struct pagevec pvec;
> > > struct page *page;
> > >
> > > - GEM_WARN_ON(IS_DGFX(to_i915(obj->base.dev)));
> > > + GEM_WARN_ON(IS_DGFX(i915));
> > > __i915_gem_object_release_shmem(obj, pages, true);
> > >
> > > i915_gem_gtt_finish_pages(obj, pages);
> > > @@ -325,7 +326,12 @@ void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct sg_
> > > }
> > > if (pagevec_count(&pvec))
> > > check_release_pagevec(&pvec);
> > > - obj->mm.dirty = false;
> > > +
> > > + /* See the comment in shmem_object_init() for why we need this */
> > > + if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
> > > + obj->mm.dirty = true;
> > > + else
> > > + obj->mm.dirty = false;
> > >
> > > sg_free_table(pages);
> > > kfree(pages);
> > > @@ -539,6 +545,25 @@ static int shmem_object_init(struct intel_memory_region *mem,
> > >
> > > i915_gem_object_set_cache_coherency(obj, cache_level);
> > >
> > > + /*
> > > + * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
> > > + * possible for userspace to bypass the GTT caching bits set by the
> > > + * kernel, as per the given object cache_level. This is troublesome
> > > + * since the heavy flush we apply when first gathering the pages is
> > > + * skipped if the kernel thinks the object is coherent with the GPU. As
> > > + * a result it might be possible to bypass the cache and read the
> > > + * contents of the page directly, which could be stale data. If it's
> > > + * just a case of userspace shooting themselves in the foot then so be
> > > + * it, but since i915 takes the stance of always zeroing memory before
> > > + * handing it to userspace, we need to prevent this.
> > > + *
> > > + * By setting cache_dirty here we make the clflush when first acquiring
> > > + * the pages unconditional on such platforms. We also set this again in
> > > + * put_pages().
> > > + */
> > > + if (IS_JSL_EHL(i915) && flags & I915_BO_ALLOC_USER)
> > > + obj->cache_dirty = true;
> >
> > I don't think this is enough, because every time we drop our pages
> > shmem could move them around or swap them out, and we get fresh ones.
> > So we need to re-force this every time we grab new pages.
>
> We also rearm this in put_pages(), or at least we do in v2, so if the
> pages are swapped out or whatever it should then flush them again when
> we re-acquire the pages.
Yeah v2 looks better, that put_pages on obj->mm.dirty made no sense.
Conceptually I think it's cleaner though if we set this in get_pages,
since that's the action that requires the cleaning. But maybe that
doesn't work from a sequencing pov? I'd have thought that any time we
get to check whether we need to clflush the pages would exist already
...
Maybe it would be even cleaner if get_pages would issue the clflush
directly, long-term at least, when we have the infrastructure for
pipeline clear/move in place and make sure we never ignore such a
fence. That's perhaps conceptually the cleanest version.
-Daniel
> > Also there's already a pile of other cases (well not WB coherency
> > mode) where userspace can be clever and bypass the coherency if we
> > don't clflush first. I think it'd be really good to have all that in
> > one places as much as possible.
> >
> > Finally this is extremely tricky code, and obj->cache_dirty and
> > related stuff isn't really documented. kerneldoc for all that would be
> > really good.
>
> Ok, I'll take a look.
>
> > -Daniel
> >
> > > +
> > > i915_gem_object_init_memory_region(obj, mem);
> > >
> > > return 0;
> > > --
> > > 2.26.3
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list