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

Nathan Bourgeois <[email protected]>
Newsgroups org.freedesktop.lists.intel-xe,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel
Message-ID <CAMpTW2eXS9tBzppJvvfZ-FiwoJ5MKOAdB9sqYgCDPVQ_+___ZA@mail.gmail.com>
> 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.

Nathan

On Thu, Aug 20, 2026 at 9:08 PM Dave Airlie <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.