Re: [PATCH] drm/xe: Fix unnecessary host-side population of ttm_tt on non-TT resources

[Matthew Brost <matthew.brost@intel.com>]

On Thu, Aug 20, 2026 at 10:34:49PM -0400, Nathan Bourgeois wrote:
> > Shouldn't we just be calling xe_bo_validate() here instead of
> > ttm_tt_populate? (With the correct xe_validation_guard() wrapping).
> 
> > Yes, this might be a better solution, making ttm_bo_setup_export()
> > completely unnecessary.
> 
> If ttm_bo_setup_export() is unnecessary, I'm happy to change the patch
> or make a new patch. I will attempt to implement and test this locally.
> 
> > This part looks good as different patch from what I'm assuming will be a
> > TTM fix.
> 
> Regarding this, what do you recommend I do, assuming the patch
> remains local to drm/xe? I'm still learning the ropes of contributing.
> 


For Xe I believe Thomas and I aligned a xe_bo_validate with a correct
xe_validation_guard is the Xe preferred solution in the existing
design... But a question to Dave below before I commit to anything.

> Nathan
> 
> On Thu, Aug 20, 2026 at 9:08 PM Dave Airlie <airlied@gmail.com> wrote:
> >
> > > Yes, this might be a better solution, making ttm_bo_setup_export()
> > > completely unnecessary.
> > >
> > > It's also a bit odd that, in flows where we don't have backing storage
> > > on export, we populate with pages and charge the system memory cgroup,
> > > only to move the data to VRAM when the import attach is triggered,
> > > resulting in a copy and a change in cgroup charging.
> > >
> > > I guess the question is why was ttm_bo_setup_export() introduced over
> > > just a validation at export?
> > >
> >
> > I'd like to think I had an answer for that, but I don't. Likely
> > because I wasn't thinking about VRAM charging at all, and just
> > worrying about making sure we had populated some pages for system
> > memory ones, so the other side couldn't DoS us.
> >

Dave:

We don't charge any cgroups yet, right? This would only come into play
once a version of [1] merges, correct?

What would prevent the pages populated for a TTM BO from being
immediately reclaimed and discarded? I'm fairly certain Xe's shrinker
could do exactly that, since we don't pin those pages. This seems to
imply that we'd need to store the cgroup associated with the TTM BO at
creation time and charge allocations to that cgroup, regardless of which
task ultimately triggers the page allocation.

Another option, instead of validating, is to revert
ttm_bo_setup_export() entirely and rethink the overall approach as part
of [1].

Matt

[1] https://patchwork.freedesktop.org/series/169831/

> > Dave.