From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Auld <matthew.auld@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
dri-devel@lists.freedesktop.org,
Chris Wilson <chris.p.wilson@intel.com>,
Francisco Jerez <francisco.jerez.plata@intel.com>
Subject: Re: [Intel-gfx] [PATCH 5/5] drm/i915/ehl: unconditionally flush the pages on acquire
Date: Wed, 14 Jul 2021 13:19:29 +0200 [thread overview]
Message-ID: <YO7IQXMS3NAmJHhk@phenom.ffwll.local> (raw)
In-Reply-To: <20210713104554.2381406-5-matthew.auld@intel.com>
On Tue, Jul 13, 2021 at 11:45:54AM +0100, Matthew Auld 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.
>
> v2: this time actually set cache_dirty in put_pages()
> v3: move to get_pages() which looks simpler
>
> BSpec: 34007
> References: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
> Cc: Francisco Jerez <francisco.jerez.plata@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Cc: Chris Wilson <chris.p.wilson@intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I was pondering whether we can have a solid testcase for this, but:
- igt lacks the visibility, since we can't check easily whether stuff
leaks.
- selftests don't have rendercopy, where we could select the nasty
mocs entry
So it's a bit awkward. Is there something, or is this pure hw workaround
stuff on theoretical grounds?
-Daniel
> ---
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 6 ++++++
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 18 ++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index da2194290436..7089d1b222c5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -522,6 +522,12 @@ struct drm_i915_gem_object {
> * I915_BO_CACHE_COHERENT_FOR_WRITE, i.e that the GPU will be coherent
> * for both reads and writes though the CPU cache. So pretty much this
> * should only be needed for I915_CACHE_NONE objects.
> + *
> + * Update: Some bonkers hardware decided to add the 'Bypass LLC' MOCS
> + * entry, which defeats our @cache_coherent tracking, since userspace
> + * can freely bypass the CPU cache when touching the pages with the GPU,
> + * where the kernel is completely unaware. On such platform we need
> + * apply the sledgehammer-on-acquire regardless of the @cache_coherent.
> */
> unsigned int cache_dirty:1;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 6a04cce188fc..11f072193f3b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -182,6 +182,24 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
> if (i915_gem_object_needs_bit17_swizzle(obj))
> i915_gem_object_do_bit_17_swizzle(obj, st);
>
> + /*
> + * 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 in set_pages
> + * unconditional on such platforms.
> + */
> + if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
> + obj->cache_dirty = true;
> +
> __i915_gem_object_set_pages(obj, st, sg_page_sizes);
>
> return 0;
> --
> 2.26.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-07-14 11:19 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 10:45 [Intel-gfx] [PATCH 1/5] drm/i915: document caching related bits Matthew Auld
2021-07-13 10:45 ` [Intel-gfx] [PATCH 2/5] drm/i915/uapi: convert drm_i915_gem_madvise to kernel-doc Matthew Auld
2021-07-13 10:45 ` [Intel-gfx] [PATCH 3/5] drm/i915: convert drm_i915_gem_object " Matthew Auld
2021-07-13 10:45 ` [Intel-gfx] [PATCH 4/5] drm/i915: pull in some more kernel-doc Matthew Auld
2021-07-13 10:45 ` [Intel-gfx] [PATCH 5/5] drm/i915/ehl: unconditionally flush the pages on acquire Matthew Auld
2021-07-14 11:19 ` Daniel Vetter [this message]
2021-07-13 11:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: document caching related bits Patchwork
2021-07-13 11:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-07-13 11:41 ` [Intel-gfx] [PATCH 1/5] " Mika Kuoppala
2021-07-13 12:59 ` [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] " Patchwork
2021-07-13 15:55 ` [Intel-gfx] [PATCH 1/5] " Ville Syrjälä
2021-07-13 16:13 ` Matthew Auld
2021-07-13 16:50 ` Daniel Vetter
2021-07-13 17:47 ` Ville Syrjälä
2021-07-13 18:24 ` Matthew Auld
2021-07-13 18:46 ` Ville Syrjälä
2021-07-14 11:16 ` Daniel Vetter
2021-07-14 11:42 ` Ville Syrjälä
2021-07-14 12:08 ` Ville Syrjälä
2021-07-14 12:57 ` Daniel Vetter
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=YO7IQXMS3NAmJHhk@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris.p.wilson@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=francisco.jerez.plata@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.auld@intel.com \
/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