public inbox for intel-xe@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
	Arvind Yadav <arvind.yadav@intel.com>
Cc: intel-xe@lists.freedesktop.org, himal.prasad.ghimiray@intel.com,
	 pallavi.mishra@intel.com
Subject: Re: [PATCH v4 7/8] drm/xe/madvise: Block imported and exported dma-bufs
Date: Fri, 23 Jan 2026 14:31:31 +0100	[thread overview]
Message-ID: <06e2e9a9493b5389c9bf01304ea248dd3c86c8e4.camel@linux.intel.com> (raw)
In-Reply-To: <aW/ArJw02DG/6wHv@lstrano-desk.jf.intel.com>

On Tue, 2026-01-20 at 09:51 -0800, Matthew Brost wrote:
> On Tue, Jan 20, 2026 at 11:38:53AM +0530, Arvind Yadav wrote:
> > Prevent marking imported or exported dma-bufs as purgeable.
> > External devices may be accessing these buffers without our
> > knowledge, making purging unsafe.
> > 
> > Check drm_gem_is_imported() for buffers created by other
> > drivers and obj->dma_buf for buffers exported to other
> > drivers. Silently skip these BOs during madvise processing.
> > 
> > This follows drm_gem_shmem's purgeable implementation and
> > prevents data corruption from purging actively-used shared
> > buffers.
> > 
> > v3:
> >    - Addresses review feedback from Matt Roper about handling
> >      imported/exported BOs correctly in the purgeable BO
> >      implementation.
> > 
> > v4:
> >    - Check should be add to xe_vm_madvise_purgeable_bo.
> > 
> > Cc: Matthew Brost <matthew.brost@intel.com>
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> 
> @Thomas - couple questions below here I need a 2nd opinion on.
> 
> > Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> > Signed-off-by: Arvind Yadav <arvind.yadav@intel.com>
> > ---
> >  drivers/gpu/drm/xe/xe_vm_madvise.c | 33
> > ++++++++++++++++++++++++++++++
> >  1 file changed, 33 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c
> > b/drivers/gpu/drm/xe/xe_vm_madvise.c
> > index 27b6ad65b314..5808fef89777 100644
> > --- a/drivers/gpu/drm/xe/xe_vm_madvise.c
> > +++ b/drivers/gpu/drm/xe/xe_vm_madvise.c
> > @@ -180,6 +180,31 @@ static void madvise_pat_index(struct xe_device
> > *xe, struct xe_vm *vm,
> >  	}
> >  }
> >  
> > +/**
> > + * xe_bo_is_external_dmabuf() - Check if BO is imported or
> > exported dma-buf
> > + * @bo: Buffer object
> > + *
> > + * Prevent marking imported or exported dma-bufs as purgeable.
> > + * External devices may be accessing these buffers without our
> > + * knowledge, making purging unsafe.
> > + *
> > + * Return: true if BO is imported or exported, false otherwise
> > + */
> > +static bool xe_bo_is_external_dmabuf(struct xe_bo *bo)
> > +{
> 
> @Thomas
> 
> Should we have this check more generic? e.g., if a BO is not tied to
> a
> VM, we don't allow purablity to be set?

I think if NEO is going to implement this in one form or another, we
need to support also external bos as long as they're not exported,
since NEO refuses to use local bos.

> 
> > +	struct drm_gem_object *obj = &bo->ttm.base;
> > +
> > +	/* Imported from another driver */
> > +	if (drm_gem_is_imported(obj))
> > +		return true;
> > +
> > +	/* Exported to another driver */
> > +	if (obj->dma_buf)
> > +		return true;
> > +
> > +	return false;
> > +}
> > +
> >  /**
> >   * xe_bo_all_vmas_dontneed() - Check if all VMAs of a BO are
> > marked DONTNEED
> >   * @bo: Buffer object
> > @@ -200,6 +225,10 @@ static bool xe_bo_all_vmas_dontneed(struct
> > xe_bo *bo)
> >  
> >  	dma_resv_assert_held(bo->ttm.base.resv);
> >  
> > +	/* External dma-bufs cannot be purgeable */
> > +	if (xe_bo_is_external_dmabuf(bo))
> > +		return false;
> > +
> >  	drm_gem_for_each_gpuvm_bo(vm_bo, obj) {
> >  		drm_gpuvm_bo_for_each_va(gpuva, vm_bo) {
> >  			struct xe_vma *vma = gpuva_to_vma(gpuva);
> > @@ -277,6 +306,10 @@ static bool xe_vm_madvise_purgeable_bo(struct
> > xe_device *xe, struct xe_vm *vm,
> >  		/* BO must be locked before modifying madv state
> > */
> >  		xe_bo_assert_held(bo);
> >  
> > +		/* Skip external dma-bufs */
> > +		if (xe_bo_is_external_dmabuf(bo))
> > +			continue;
> 
> @Thomas
> 
> I think instead of silently continuing here we fail the IOCTL with
> -EINVAL?
> 
> What do you think?

Hmm. If we view the export as yet another map, then IMO silently
continuing would probably be the best option and consistent with
sharing across VMs.

Finally I wonder if we should update the purgeable state on final dma-
buf attach.

Floating an idea here:

Could the code be simplified if we maintain a map_count and a
purgeable_count on each bo? Bo is purgeable iff map_count ==
purgeable_count. vmas and dma-buf attachments are included in
map_count.

Thanks,
Thomas


> 
> Matt
> 
> > +
> >  		/*
> >  		 * Once purged, always purged. Cannot transition
> > back to WILLNEED.
> >  		 * This matches i915 semantics where purged BOs
> > are permanently invalid.
> > -- 
> > 2.43.0
> > 

  reply	other threads:[~2026-01-23 13:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20  6:08 [PATCH v4 0/8] drm/xe/madvise: Add support for purgeable buffer objects Arvind Yadav
2026-01-20  6:08 ` [PATCH v4 1/8] drm/xe/uapi: Add UAPI " Arvind Yadav
2026-01-20 17:20   ` Matthew Brost
2026-01-21 18:42     ` Vivi, Rodrigo
2026-01-20  6:08 ` [PATCH v4 2/8] drm/xe/bo: Add purgeable bo state tracking and field madv to xe_bo Arvind Yadav
2026-01-20 17:45   ` Matthew Brost
2026-01-21  5:30     ` Yadav, Arvind
2026-01-22 15:05     ` Thomas Hellström
2026-01-20  6:08 ` [PATCH v4 3/8] drm/xe/madvise: Implement purgeable buffer object support Arvind Yadav
2026-01-20 16:58   ` Matthew Brost
2026-01-20 17:15     ` Matthew Brost
2026-01-21  8:24       ` Yadav, Arvind
2026-01-22 15:30     ` Thomas Hellström
2026-01-30  8:13       ` Yadav, Arvind
2026-01-20 17:44   ` Matthew Brost
2026-01-20  6:08 ` [PATCH v4 4/8] drm/xe/bo: Handle CPU faults on purged buffer objects Arvind Yadav
2026-01-20 17:23   ` Matthew Brost
2026-01-22 15:54   ` Thomas Hellström
2026-01-20  6:08 ` [PATCH v4 5/8] drm/xe/vm: Prevent binding of " Arvind Yadav
2026-01-20 17:27   ` Matthew Brost
2026-01-23  5:41     ` Yadav, Arvind
2026-01-23 12:37       ` Thomas Hellström
2026-01-30  8:17         ` Yadav, Arvind
2026-01-20  6:08 ` [PATCH v4 6/8] drm/xe/madvise: Implement per-VMA purgeable state tracking Arvind Yadav
2026-01-20 17:41   ` Matthew Brost
2026-01-21  5:11     ` Yadav, Arvind
2026-01-23 13:07     ` Thomas Hellström
2026-01-20  6:08 ` [PATCH v4 7/8] drm/xe/madvise: Block imported and exported dma-bufs Arvind Yadav
2026-01-20 17:51   ` Matthew Brost
2026-01-23 13:31     ` Thomas Hellström [this message]
2026-01-30  8:22       ` Yadav, Arvind
2026-01-30  8:59         ` Thomas Hellström
2026-01-20  6:08 ` [PATCH v4 8/8] drm/xe/bo: Add purgeable shrinker state helpers Arvind Yadav
2026-01-20 17:58   ` Matthew Brost
2026-01-23 13:42     ` Thomas Hellström
2026-01-20  6:14 ` ✗ CI.checkpatch: warning for drm/xe/madvise: Add support for purgeable buffer objects (rev5) Patchwork
2026-01-20  6:16 ` ✗ CI.KUnit: 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=06e2e9a9493b5389c9bf01304ea248dd3c86c8e4.camel@linux.intel.com \
    --to=thomas.hellstrom@linux.intel.com \
    --cc=arvind.yadav@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=pallavi.mishra@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