Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Christian König" <ckoenig.leichtzumerken@gmail.com>,
	"Simona Vetter" <simona.vetter@ffwll.ch>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Huang Rui" <ray.huang@amd.com>,
	intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	matthew.auld@intel.com, "David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>
Subject: Re: [PATCH v6 2/8] drm/ttm: Add ttm_bo_access
Date: Mon, 25 Nov 2024 09:27:17 -0800	[thread overview]
Message-ID: <Z0SzddLDzR8NDWmV@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <634b07dd-aa5a-410e-8f62-0a96567c7932@amd.com>

On Mon, Nov 25, 2024 at 05:19:54PM +0100, Christian König wrote:
> Am 25.11.24 um 16:29 schrieb Matthew Brost:
> > On Fri, Nov 15, 2024 at 10:27:59AM -0800, Matthew Brost wrote:
> > > [SNIP]
> > > We use this interface to read a BO marked with a dumpable flag during a
> > > GPU hang in our error capture code. This is an internal KMD feature, not
> > > directly exposed to user space. Would adding this helper be acceptable
> > > for this use case? I can add kernel indicating the current restrictions
> > > of the helper (do not directly expose to user space) too if that would
> > > help.
> > > 
> > Christian - ping on above.
> 
> Sorry, I will try to give those mailing list tasks a bit more time in before
> the xmas holidays.
> 
> That is an acceptable use case, but the problem is that this helper won't
> work for that.
> 
> See during a GPU hang you can't lock BOs, so how do you want to look into
> their content with the peek helper?
> 

Agree we cannot lock BO directly in GPU hang path (TDR). Our error
capture code takes a snapshot of some the GPU state which is small and
safe to capture in TDR and kicks a worker which opportunistically
captures the VM state which has been marked to be captured. This is
where the helper is called and it is safe to lock the BO.

Matt

> The only thing you could potentially do is to trylock the BO and then dump,
> but that would most likely be a bit unreliable.
> 
> Regards,
> Christian.
> 
> > > Matt

  reply	other threads:[~2024-11-25 17:26 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31 18:10 [PATCH v6 0/8] Fix non-contiguous VRAM BO access in Xe Matthew Brost
2024-10-31 18:10 ` [PATCH v6 1/8] drm/xe: Add xe_bo_vm_access Matthew Brost
2024-10-31 18:10 ` [PATCH v6 2/8] drm/ttm: Add ttm_bo_access Matthew Brost
2024-10-31 23:43   ` Matthew Brost
2024-11-04 17:34     ` Rodrigo Vivi
2024-11-04 19:28       ` Christian König
2024-11-04 21:49         ` Matthew Brost
2024-11-05  7:41           ` Christian König
2024-11-05 18:35             ` Matthew Brost
2024-11-06  9:48               ` Christian König
2024-11-06 15:25                 ` Matthew Brost
2024-11-06 15:44                   ` Christian König
2024-11-06 17:00                     ` Matthew Brost
2024-11-07  9:44                       ` Christian König
2024-11-11  8:00                         ` Joonas Lahtinen
2024-11-11 10:10                           ` Simona Vetter
2024-11-11 11:34                             ` Christian König
2024-11-11 14:00                               ` Joonas Lahtinen
2024-11-11 15:54                                 ` Christian König
2024-11-11 22:45                                   ` Matthew Brost
2024-11-12  9:23                                     ` Christian König
2024-11-12 13:41                                       ` Joonas Lahtinen
2024-11-12 16:22                                         ` Thomas Hellström
2024-11-12 16:25                                           ` Christian König
2024-11-12 16:33                                             ` Thomas Hellström
2024-11-13  8:37                                               ` Christian König
2024-11-13 10:44                                                 ` Thomas Hellström
2024-11-13 11:42                                                   ` Christian König
2024-11-15 18:27                                                     ` Matthew Brost
2024-11-25 15:29                                                       ` Matthew Brost
2024-11-25 16:19                                                         ` Christian König
2024-11-25 17:27                                                           ` Matthew Brost [this message]
2024-11-26  8:19                                                             ` Christian König
2024-11-26 17:49                                                               ` Matthew Brost
2024-11-27 13:21                                                                 ` Christian König
2024-11-12  8:28                                 ` Simona Vetter
2024-11-12  8:58                                   ` Christian König
2024-11-12 13:30                                     ` Joonas Lahtinen
2024-11-11 11:27                           ` Christian König
2024-11-04 19:47     ` Christian König
2024-11-04 21:30       ` Matthew Brost
2024-11-04 22:26         ` Rodrigo Vivi
2024-10-31 18:10 ` [PATCH v6 3/8] drm/xe: Add xe_ttm_access_memory Matthew Brost
2024-10-31 18:10 ` [PATCH v6 4/8] drm/xe: Take PM ref in delayed snapshot capture worker Matthew Brost
2024-10-31 18:10 ` [PATCH v6 5/8] drm/xe/display: Update intel_bo_read_from_page to use ttm_bo_access Matthew Brost
2024-10-31 18:10 ` [PATCH v6 6/8] drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed Matthew Brost
2024-10-31 18:10 ` [PATCH v6 7/8] drm/xe: Set XE_BO_FLAG_PINNED in migrate selftest BOs Matthew Brost
2024-10-31 18:10 ` [PATCH v6 8/8] drm/xe: Only allow contiguous BOs to use xe_bo_vmap Matthew Brost
2024-10-31 18:15 ` ✓ CI.Patch_applied: success for Fix non-contiguous VRAM BO access in Xe (rev6) Patchwork
2024-10-31 18:15 ` ✗ CI.checkpatch: warning " Patchwork
2024-10-31 18:17 ` ✓ CI.KUnit: success " Patchwork
2024-10-31 18:28 ` ✓ CI.Build: " Patchwork
2024-10-31 18:31 ` ✓ CI.Hooks: " Patchwork
2024-10-31 18:32 ` ✗ CI.checksparse: warning " Patchwork
2024-10-31 18:57 ` ✓ CI.BAT: success " Patchwork
2024-10-31 21:27 ` ✗ CI.FULL: failure " 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=Z0SzddLDzR8NDWmV@lstrano-desk.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=airlied@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=matthew.auld@intel.com \
    --cc=ray.huang@amd.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=simona@ffwll.ch \
    --cc=thomas.hellstrom@linux.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