From: Matthew Brost <matthew.brost@intel.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "Christian König" <christian.koenig@amd.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.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: Tue, 26 Nov 2024 09:49:20 -0800 [thread overview]
Message-ID: <Z0YKIGToB3pE+uZz@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <18681d07-beb4-41c5-a935-11b8ec231c27@gmail.com>
On Tue, Nov 26, 2024 at 09:19:47AM +0100, Christian König wrote:
> Am 25.11.24 um 18:27 schrieb Matthew Brost:
> > 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.
>
> Yeah that sounds like it should work.
>
> No objections from my side for that use case, but I would rather like to
> keep the code inside ttm_bo_vm.c.
>
Thanks, reposted with code inside ttm_bo_vm.c. Any objection to merging
entire series through drm-xe-next and then backporting single TTM patch
drm-misc-next?
Matt
> Crash dumping is usually something associated with the VMA even if it's a
> bit special here for the VM state.
>
> Regards,
> Christian.
>
> >
> > 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
>
next prev parent reply other threads:[~2024-11-26 17:48 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
2024-11-26 8:19 ` Christian König
2024-11-26 17:49 ` Matthew Brost [this message]
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=Z0YKIGToB3pE+uZz@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