From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, matthew.auld@intel.com Subject: [PATCH v2 0/2] drm/i915: Failsafe migration blits Date: Mon, 1 Nov 2021 19:38:49 +0100 [thread overview] Message-ID: <20211101183851.291015-1-thomas.hellstrom@linux.intel.com> (raw) This patch series introduces failsafe migration blits. The reason for this seemingly strange concept is that if the initial clearing or readback of LMEM fails for some reason[1], and we then set up either GPU- or CPU ptes to the allocated LMEM, we can expose old contents from other clients. So after each migration blit to LMEM, attach a dma-fence callback that checks the migration fence error value and if it's an error, performs a memcpy blit, instead. Patch 1 splits out the TTM move code into separate files Patch 2 implements the failsafe blits and related self-tests [1] There are at least two ways we could trigger exposure of uninitialized LMEM assuming the migration blits themselves never trigger a gpu hang. a) A gpu operation preceding a pipelined eviction blit resets and sets the error fence to -EIO, and the error is propagated across the TTM manager to the clear / swapin blit of a newly allocated TTM resource. It aborts and leaves the memory uninitialized. b) Something wedges the GT while a migration blit is submitted. It ends up never executed and TTM can fault user-space cpu-ptes into uninitialized memory. Thomas Hellström (2): drm/i915/ttm: Reorganize the ttm move code drm/i915/ttm: Failsafe migration blits drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 ++--------- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 520 ++++++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 43 ++ .../drm/i915/gem/selftests/i915_gem_migrate.c | 24 +- 6 files changed, 670 insertions(+), 281 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h -- 2.31.1
WARNING: multiple messages have this Message-ID (diff)
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>, matthew.auld@intel.com Subject: [Intel-gfx] [PATCH v2 0/2] drm/i915: Failsafe migration blits Date: Mon, 1 Nov 2021 19:38:49 +0100 [thread overview] Message-ID: <20211101183851.291015-1-thomas.hellstrom@linux.intel.com> (raw) This patch series introduces failsafe migration blits. The reason for this seemingly strange concept is that if the initial clearing or readback of LMEM fails for some reason[1], and we then set up either GPU- or CPU ptes to the allocated LMEM, we can expose old contents from other clients. So after each migration blit to LMEM, attach a dma-fence callback that checks the migration fence error value and if it's an error, performs a memcpy blit, instead. Patch 1 splits out the TTM move code into separate files Patch 2 implements the failsafe blits and related self-tests [1] There are at least two ways we could trigger exposure of uninitialized LMEM assuming the migration blits themselves never trigger a gpu hang. a) A gpu operation preceding a pipelined eviction blit resets and sets the error fence to -EIO, and the error is propagated across the TTM manager to the clear / swapin blit of a newly allocated TTM resource. It aborts and leaves the memory uninitialized. b) Something wedges the GT while a migration blit is submitted. It ends up never executed and TTM can fault user-space cpu-ptes into uninitialized memory. Thomas Hellström (2): drm/i915/ttm: Reorganize the ttm move code drm/i915/ttm: Failsafe migration blits drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 ++--------- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 520 ++++++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 43 ++ .../drm/i915/gem/selftests/i915_gem_migrate.c | 24 +- 6 files changed, 670 insertions(+), 281 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h -- 2.31.1
next reply other threads:[~2021-11-01 19:13 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-01 18:38 Thomas Hellström [this message] 2021-11-01 18:38 ` [Intel-gfx] [PATCH v2 0/2] drm/i915: Failsafe migration blits Thomas Hellström 2021-11-01 18:38 ` [PATCH v2 1/2] drm/i915/ttm: Reorganize the ttm move code Thomas Hellström 2021-11-01 18:38 ` [Intel-gfx] " Thomas Hellström 2021-11-02 8:52 ` Matthew Auld 2021-11-02 8:52 ` [Intel-gfx] " Matthew Auld 2021-11-01 18:38 ` [PATCH v2 2/2] drm/i915/ttm: Failsafe migration blits Thomas Hellström 2021-11-01 18:38 ` [Intel-gfx] " Thomas Hellström 2021-11-02 13:55 ` Matthew Auld 2021-11-02 13:55 ` Matthew Auld 2021-11-02 14:14 ` Thomas Hellström 2021-11-02 14:14 ` [Intel-gfx] " Thomas Hellström 2021-11-01 22:33 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Failsafe migration blits (rev2) Patchwork 2021-11-01 23:05 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-11-02 2:59 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-11-02 5:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Failsafe migration blits (rev3) Patchwork 2021-11-02 6:29 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-11-02 7:47 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork 2021-11-02 8:18 ` Thomas Hellström 2021-11-02 15:41 ` Vudum, Lakshminarayana 2021-11-02 15:38 ` [Intel-gfx] ✓ Fi.CI.IGT: success " 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=20211101183851.291015-1-thomas.hellstrom@linux.intel.com \ --to=thomas.hellstrom@linux.intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --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: linkBe 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.