From: Matthew Brost <matthew.brost@intel.com>
To: "Upadhyay, Tejas" <tejas.upadhyay@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"Auld, Matthew" <matthew.auld@intel.com>,
"thomas.hellstrom@linux.intel.com"
<thomas.hellstrom@linux.intel.com>,
"Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
Subject: Re: [RFC PATCH V6 1/7] drm/xe: Link VRAM object with gpu buddy
Date: Thu, 2 Apr 2026 13:50:09 -0700 [thread overview]
Message-ID: <ac7WgTPbXAwAPibW@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <SJ1PR11MB6204361A01C00EABBEB1986D8151A@SJ1PR11MB6204.namprd11.prod.outlook.com>
On Thu, Apr 02, 2026 at 03:10:02AM -0600, Upadhyay, Tejas wrote:
>
>
> > -----Original Message-----
> > From: Brost, Matthew <matthew.brost@intel.com>
> > Sent: 02 April 2026 05:27
> > To: Upadhyay, Tejas <tejas.upadhyay@intel.com>
> > Cc: intel-xe@lists.freedesktop.org; Auld, Matthew
> > <matthew.auld@intel.com>; thomas.hellstrom@linux.intel.com; Ghimiray,
> > Himal Prasad <himal.prasad.ghimiray@intel.com>
> > Subject: Re: [RFC PATCH V6 1/7] drm/xe: Link VRAM object with gpu buddy
> >
> > On Fri, Mar 27, 2026 at 05:18:14PM +0530, Tejas Upadhyay wrote:
> > > Setup to link TTM buffer object inside gpu buddy. This functionality
> > > is critical for supporting the memory page offline feature on CRI,
> > > where identified faulty pages must be traced back to their originating
> > > buffer for safe removal.
> > >
> >
> > I just checked the SVM code is still setting 'block->private'.
> >
> > I thought we had patch for that but I don't see it in this series.
>
> Yeah, you are right, it was there when I sent earlier revision, I somehow missed adding that patch in this series. I will add it back in next revision. Sorry for confusion here.
>
Also free to send that as indepent patch as we should be able to merge
that one whenever.
Another comment.
> Tejas
> >
> > Matt
> >
> > > Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
> > > ---
> > > drivers/gpu/drm/xe/xe_ttm_vram_mgr.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > index 5fd0d5506a7e..c627dbf94552 100644
> > > --- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > +++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> > > @@ -54,6 +54,7 @@ static int xe_ttm_vram_mgr_new(struct
> > ttm_resource_manager *man,
> > > struct xe_ttm_vram_mgr *mgr = to_xe_ttm_vram_mgr(man);
> > > struct xe_ttm_vram_mgr_resource *vres;
> > > struct gpu_buddy *mm = &mgr->mm;
> > > + struct gpu_buddy_block *block;
> > > u64 size, min_page_size;
> > > unsigned long lpfn;
> > > int err;
> > > @@ -138,6 +139,8 @@ static int xe_ttm_vram_mgr_new(struct
> > ttm_resource_manager *man,
> > > }
> > >
> > > mgr->visible_avail -= vres->used_visible_size;
> > > + list_for_each_entry(block, &vres->blocks, link)
> > > + block->private = tbo;
Should we clear block->private in xe_ttm_vram_mgr_del() to avoid blocks
having stale references to BOs? Or are there guarantees elsewhere in the
code that a free block cannot reference block->private as a BO if it
encounters an error while in a free state? For safety and clarity, even
if such guarantees exist, it may still make sense to clear
block->private in xe_ttm_vram_mgr_del().
Matt
> > > mutex_unlock(&mgr->lock);
> > >
> > > if (!(vres->base.placement & TTM_PL_FLAG_CONTIGUOUS) &&
> > > --
> > > 2.52.0
> > >
next prev parent reply other threads:[~2026-04-02 20:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 11:48 [RFC PATCH V6 0/7] Add memory page offlining support Tejas Upadhyay
2026-03-27 11:48 ` [RFC PATCH V6 1/7] drm/xe: Link VRAM object with gpu buddy Tejas Upadhyay
2026-04-01 23:56 ` Matthew Brost
2026-04-02 9:10 ` Upadhyay, Tejas
2026-04-02 20:50 ` Matthew Brost [this message]
2026-04-06 11:04 ` Upadhyay, Tejas
2026-03-27 11:48 ` [RFC PATCH V6 2/7] drm/gpu: Add gpu_buddy_addr_to_block helper Tejas Upadhyay
2026-04-02 0:09 ` Matthew Brost
2026-04-02 10:16 ` Matthew Auld
2026-04-13 13:13 ` Upadhyay, Tejas
2026-04-02 9:12 ` Matthew Auld
2026-04-13 14:17 ` Upadhyay, Tejas
2026-03-27 11:48 ` [RFC PATCH V6 3/7] drm/xe: Handle physical memory address error Tejas Upadhyay
2026-04-01 23:53 ` Matthew Brost
2026-04-02 1:03 ` Matthew Brost
2026-04-02 10:30 ` Upadhyay, Tejas
2026-04-02 20:20 ` Matthew Brost
2026-04-07 12:03 ` Upadhyay, Tejas
2026-03-27 11:48 ` [RFC PATCH V6 4/7] drm/xe/cri: Add debugfs to inject faulty vram address Tejas Upadhyay
2026-03-27 11:48 ` [RFC PATCH V6 5/7] gpu/buddy: Add routine to dump allocated buddy blocks Tejas Upadhyay
2026-03-27 11:48 ` [RFC PATCH V6 6/7] drm/xe/configfs: Add vram bad page reservation policy Tejas Upadhyay
2026-03-27 11:48 ` [RFC PATCH V6 7/7] drm/xe/cri: Add sysfs interface for bad gpu vram pages Tejas Upadhyay
2026-03-27 12:24 ` ✗ CI.checkpatch: warning for Add memory page offlining support (rev6) Patchwork
2026-03-27 12:26 ` ✓ CI.KUnit: success " Patchwork
2026-03-27 13:16 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-28 4:49 ` ✓ Xe.CI.FULL: " 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=ac7WgTPbXAwAPibW@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=tejas.upadhyay@intel.com \
--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 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.