All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v3 19/19] drm/xe/bo: Update atomic_access attribute on madvise
Date: Thu, 29 May 2025 11:24:28 -0700	[thread overview]
Message-ID: <aDimXEhce5BUR7+J@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <1d9199e9-bcaf-4755-9ce6-d9b6bfec2bc0@intel.com>

On Thu, May 29, 2025 at 08:33:39AM +0530, Ghimiray, Himal Prasad wrote:
> 
> 
> On 29-05-2025 05:16, Matthew Brost wrote:
> > On Tue, May 27, 2025 at 10:10:03PM +0530, Himal Prasad Ghimiray wrote:
> > > Update the bo_atomic_access based on user-provided input and determine
> > > the migration to smem during a CPU fault
> > > 
> > > v2 (Matthew Brost)
> > > - Avoid cpu unmapping if bo is already in smem
> > > - check atomics on smem too for ioctl
> > > - Add comments
> > > 
> > > Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> > > ---
> > >   drivers/gpu/drm/xe/xe_bo.c         | 21 ++++++++++++--
> > >   drivers/gpu/drm/xe/xe_vm.c         | 11 ++++++--
> > >   drivers/gpu/drm/xe/xe_vm_madvise.c | 45 ++++++++++++++++++++++++++++--
> > >   3 files changed, 69 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> > > index d99d91fe8aa9..9072e8ae3f3e 100644
> > > --- a/drivers/gpu/drm/xe/xe_bo.c
> > > +++ b/drivers/gpu/drm/xe/xe_bo.c
> > > @@ -1662,6 +1662,12 @@ static void xe_gem_object_close(struct drm_gem_object *obj,
> > >   	}
> > >   }
> > > +static bool should_migrate_to_smem(struct xe_bo *bo)
> > > +{
> > 
> > xe_bo_assert_held, more on that in reply to previous patch.
> 
> Sure
> 
> > 
> > > +	return bo->attr.atomic_access == DRM_XE_VMA_ATOMIC_GLOBAL ||
> > > +	       bo->attr.atomic_access == DRM_XE_VMA_ATOMIC_CPU;
> > > +}
> > > +
> > 
> > Hmm, this is tricky. I guess this means sharded atomics on BOs do not
> > just work whereas for SVM they do (i.e., DRM_XE_VMA_ATOMIC_UNDEFINED
> > means atomics do not work for BOs but for SVM they do). I suppose this
> > is the current behavior. I think this will need to be document in the
> > uAPI kernel doc.
> 
> Makes sense
> 
> > 
> > >   static vm_fault_t xe_gem_fault(struct vm_fault *vmf)
> > >   {
> > >   	struct ttm_buffer_object *tbo = vmf->vma->vm_private_data;
> > > @@ -1670,7 +1676,7 @@ static vm_fault_t xe_gem_fault(struct vm_fault *vmf)
> > >   	struct xe_bo *bo = ttm_to_xe_bo(tbo);
> > >   	bool needs_rpm = bo->flags & XE_BO_FLAG_VRAM_MASK;
> > >   	vm_fault_t ret;
> > > -	int idx;
> > > +	int idx, r = 0;
> > >   	if (needs_rpm)
> > >   		xe_pm_runtime_get(xe);
> > > @@ -1682,8 +1688,17 @@ static vm_fault_t xe_gem_fault(struct vm_fault *vmf)
> > >   	if (drm_dev_enter(ddev, &idx)) {
> > >   		trace_xe_bo_cpu_fault(bo);
> > > -		ret = ttm_bo_vm_fault_reserved(vmf, vmf->vma->vm_page_prot,
> > > -					       TTM_BO_VM_NUM_PREFAULT);
> > > +		if (should_migrate_to_smem(bo)) {
> > > +			r = xe_bo_migrate(bo, XE_PL_TT);
> > > +			if (r == -EBUSY || r == -ERESTARTSYS || r == -EINTR)
> > > +				ret = VM_FAULT_NOPAGE;
> > > +			else if (r)
> > > +				ret = VM_FAULT_SIGBUS;
> > > +		}
> > > +		if (!ret)
> > > +			ret = ttm_bo_vm_fault_reserved(vmf,
> > > +						       vmf->vma->vm_page_prot,
> > > +						       TTM_BO_VM_NUM_PREFAULT);
> > >   		drm_dev_exit(idx);
> > >   	} else {
> > >   		ret = ttm_bo_vm_dummy_page(vmf, vmf->vma->vm_page_prot);
> > > diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> > > index 9611d7ca2bed..1bdf85c12374 100644
> > > --- a/drivers/gpu/drm/xe/xe_vm.c
> > > +++ b/drivers/gpu/drm/xe/xe_vm.c
> > > @@ -3116,9 +3116,16 @@ static int op_lock_and_prep(struct drm_exec *exec, struct xe_vm *vm,
> > >   		err = vma_lock_and_validate(exec,
> > >   					    gpuva_to_vma(op->base.prefetch.va),
> > >   					    false);
> > > -		if (!err && !xe_vma_has_no_bo(vma))
> > > -			err = xe_bo_migrate(xe_vma_bo(vma),
> > > +		if (!err && !xe_vma_has_no_bo(vma)) {
> > > +			struct xe_bo *bo = xe_vma_bo(vma);
> > > +
> > > +			if (region == 0 && !vm->xe->info.has_device_atomics_on_smem &&
> > > +			    bo->attr.atomic_access == DRM_XE_VMA_ATOMIC_DEVICE)
> > > +				region = 1;
> > 
> > I wonder if it better to just leave region as is and let the next atomic
> > fault trigger the migration.
> 
> Ok. lets do it that way.
> 
> > 
> > > +
> > > +			err = xe_bo_migrate(bo,
> > >   					    region_to_mem_type[region]);
> > > +		}
> > >   		break;
> > >   	}
> > >   	default:
> > > diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c b/drivers/gpu/drm/xe/xe_vm_madvise.c
> > > index 0f0b94cb43f2..e048eb48826c 100644
> > > --- a/drivers/gpu/drm/xe/xe_vm_madvise.c
> > > +++ b/drivers/gpu/drm/xe/xe_vm_madvise.c
> > > @@ -82,15 +82,54 @@ static int madvise_atomic(struct xe_device *xe, struct xe_vm *vm,
> > >   			  struct xe_vma **vmas, int num_vmas,
> > >   			  struct drm_xe_madvise_ops ops)
> > >   {
> > > -	int i;
> > > +	struct xe_bo *bo;
> > > +	int err, i;
> > >   	xe_assert(vm->xe, ops.type == DRM_XE_VMA_ATTR_ATOMIC);
> > >   	xe_assert(vm->xe, ops.atomic.val > DRM_XE_VMA_ATOMIC_UNDEFINED &&
> > >   		  ops.atomic.val <= DRM_XE_VMA_ATOMIC_CPU);
> > 
> > Do you sanitize ops.atomic.val prior to this? Also do we disallow a user
> > setting DRM_XE_VMA_ATOMIC_UNDEFINED? If not, then this needs to be >=
> > DRM_XE_VMA_ATOMIC_UNDEFINED.
> Agreed it should be  >= DRM_XE_VMA_ATOMIC_UNDEFINED. And instead of
> assertion will sanitize it here only.
> 
> > 
> > > -	for (i = 0; i < num_vmas; i++)
> > > +	for (i = 0; i < num_vmas; i++) {
> > >   		vmas[i]->attr.atomic_access = ops.atomic.val;
> > > -	/*TODO: handle bo backed vmas */
> > > +
> > > +		bo = xe_vma_bo(vmas[i]);
> > > +		if (!bo)
> > > +			continue;
> > > +
> > > +		if (XE_IOCTL_DBG(xe, ops.atomic.val == DRM_XE_VMA_ATOMIC_CPU &&
> > > +				 !(bo->flags & XE_BO_FLAG_SYSTEM)))
> > > +			return -EINVAL;
> > > +
> > 
> > Note when we fail here (or anywhere else in madvise), we could be in a
> > state where madvise has partially completed. I think that is actually ok
> > as nothing in madvise is fatal as we are just changing attributes. But I
> > think we need to document this in the uAPI kernel doc that if madvise
> > fails, the state of madvise attributes are undefined.
> 
> Will add in kernel-doc of uAPI.
> 

Actually, on second thought, it might be better to sanitize user input
before attempting madvise. This is similar to vm_bind_ioctl_check_args.
I think that would be cleaner.

I believe we can make the failing state stable if we can avoid failures
in madvise_funcs (i.e., by returning void), which should be possible if
we take locks in non-interruptible modes (likely fine, as we’re not
doing much inside any locks) and avoid mallocs (none are used in this
series).

We’d also have to restructure this loop:

for (i = 0; i < args->num_ops; i++) {
	xe_vm_alloc_madvise_vma(vm, advs_ops[i].start, advs_ops[i].range);

	vmas = get_vmas(vm, &num_vmas, advs_ops[i].start, advs_ops[i].range);
	if (!vmas) {
		err = -ENOMEM;
		goto free_advs_ops;
	}

	attr_type = array_index_nospec(advs_ops[i].type, ARRAY_SIZE(madvise_funcs));
	err = madvise_funcs[attr_type](xe, vm, vmas, num_vmas, advs_ops[i]);

	kfree(vmas);
	vmas = NULL;

	if (err)
		goto free_advs_ops;
}

xe_vm_alloc_madvise_vma and get_vmas would run in the first loop (which
can fail), followed by a second loop that calls madvise_funcs (which
cannot fail). If the first loop fails, the worst-case scenario is that
we've split some VMAs into smaller ones, but their attributes would
remain the same as before the IOCTL.

I think this approach would be better avoiding a unknown state on
failure.

Matt

> > 
> > In practice this really should never fail unless a user is giving bad
> > input or extreme memory pressure and kmalloc fails.
> > 
> > Matt
> > 
> > > +		/* NOTE: The following atomic checks are platform-specific. For example,
> > > +		 * if a device supports CXL atomics, these may not be necessary or
> > > +		 * may behave differently.
> > > +		 */
> > > +		if (XE_IOCTL_DBG(xe, ops.atomic.val == DRM_XE_VMA_ATOMIC_DEVICE &&
> > > +				 !(bo->flags & XE_BO_FLAG_VRAM0) &&
> > > +				 !(bo->flags & XE_BO_FLAG_VRAM1) &&
> > > +				 !(bo->flags & XE_BO_FLAG_SYSTEM &&
> > > +				   xe->info.has_device_atomics_on_smem)))
> > > +			return -EINVAL;
> > > +
> > > +		if (XE_IOCTL_DBG(xe, ops.atomic.val == DRM_XE_VMA_ATOMIC_GLOBAL &&
> > > +				 (!(bo->flags & XE_BO_FLAG_SYSTEM) ||
> > > +				  (!(bo->flags & XE_BO_FLAG_VRAM0) &&
> > > +				   !(bo->flags & XE_BO_FLAG_VRAM1)))))
> > > +			return -EINVAL;
> > > +
> > > +		err = xe_bo_lock(bo, true);
> > > +		if (err)
> > > +			return err;
> > > +		bo->attr.atomic_access = ops.atomic.val;
> > > +
> > > +		/* Invalidate cpu page table, so bo can migrate to smem in next access */
> > > +		if (xe_bo_is_vram(bo) &&
> > > +		    (bo->attr.atomic_access == DRM_XE_VMA_ATOMIC_CPU ||
> > > +		     bo->attr.atomic_access == DRM_XE_VMA_ATOMIC_GLOBAL))
> > > +			ttm_bo_unmap_virtual(&bo->ttm);
> > > +
> > > +		xe_bo_unlock(bo);
> > > +	}
> > >   	return 0;
> > >   }
> > > -- 
> > > 2.34.1
> > > 
> 

  reply	other threads:[~2025-05-29 18:23 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27 16:39 [PATCH v3 00/19] MADVISE FOR XE Himal Prasad Ghimiray
2025-05-27 16:39 ` [PATCH v3 01/19] Introduce drm_gpuvm_sm_map_ops_flags enums for sm_map_ops Himal Prasad Ghimiray
2025-05-27 16:39 ` [PATCH v3 02/19] drm/xe/uapi: Add madvise interface Himal Prasad Ghimiray
2025-05-28 16:27   ` Matthew Brost
2025-05-28 17:03   ` Souza, Jose
2025-05-29 18:03     ` Matthew Brost
2025-05-29 18:00   ` Matthew Brost
2025-06-10  4:32     ` Ghimiray, Himal Prasad
2025-05-27 16:39 ` [PATCH v3 03/19] drm/xe/vm: Add attributes struct as member of vma Himal Prasad Ghimiray
2025-05-28 16:46   ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 04/19] drm/xe/vma: Move pat_index to vma attributes Himal Prasad Ghimiray
2025-05-28 22:51   ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 05/19] drm/xe/vma: Modify new_vma to accept struct xe_vma_mem_attr as parameter Himal Prasad Ghimiray
2025-05-28 22:58   ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 06/19] drm/gpusvm: Make drm_gpusvm_for_each_* macros public Himal Prasad Ghimiray
2025-05-28 23:01   ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 07/19] drm/xe/vm: Add a helper xe_vm_range_tilemask_tlb_invalidation() Himal Prasad Ghimiray
2025-05-28 23:12   ` Matthew Brost
2025-05-29  3:21     ` Ghimiray, Himal Prasad
2025-05-27 16:39 ` [PATCH v3 08/19] drm/xe/svm: Add xe_svm_ranges_zap_ptes_in_range() for PTE zapping Himal Prasad Ghimiray
2025-05-28 23:15   ` Matthew Brost
2025-05-29  3:06     ` Ghimiray, Himal Prasad
2025-05-29  4:00       ` Matthew Brost
2025-05-30  6:29         ` Matthew Brost
2025-06-10  4:31           ` Ghimiray, Himal Prasad
2025-05-27 16:39 ` [PATCH v3 09/19] drm/xe/svm: Split system allocator vma incase of madvise call Himal Prasad Ghimiray
2025-05-29  2:49   ` Matthew Brost
2025-05-29  3:14     ` Ghimiray, Himal Prasad
2025-05-27 16:39 ` [PATCH v3 10/19] drm/xe: Implement madvise ioctl for xe Himal Prasad Ghimiray
2025-05-29 22:43   ` Matthew Brost
2025-05-30  6:36     ` Matthew Brost
2025-05-30 21:34   ` Matthew Brost
2025-06-10  4:52     ` Ghimiray, Himal Prasad
2025-06-10  5:13       ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 11/19] drm/xe: Allow CPU address mirror VMA unbind with gpu bindings for madvise Himal Prasad Ghimiray
2025-05-29 22:54   ` Matthew Brost
2025-06-12  9:02     ` Ghimiray, Himal Prasad
2025-05-27 16:39 ` [PATCH v3 12/19] drm/xe/svm : Add svm ranges migration policy on atomic access Himal Prasad Ghimiray
2025-05-29 23:27   ` Matthew Brost
2025-05-29 23:38     ` Matthew Brost
2025-05-30  4:40     ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 13/19] drm/xe/madvise: Update migration policy based on preferred location Himal Prasad Ghimiray
2025-05-29 23:42   ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 14/19] drm/xe/svm: Support DRM_XE_SVM_ATTR_PAT memory attribute Himal Prasad Ghimiray
2025-05-30  0:24   ` Matthew Brost
2025-05-27 16:39 ` [PATCH v3 15/19] drm/xe/uapi: Add flag for consulting madvise hints on svm prefetch Himal Prasad Ghimiray
2025-05-28 16:29   ` Matthew Brost
2025-05-27 16:40 ` [PATCH v3 16/19] drm/xe/svm: Consult madvise preferred location in prefetch Himal Prasad Ghimiray
2025-05-30  4:24   ` Matthew Brost
2025-06-24 18:56   ` Matthew Brost
2025-05-27 16:40 ` [PATCH v3 17/19] drm/xe/uapi: Add UAPI for querying VMA count and memory attributes Himal Prasad Ghimiray
2025-05-28 17:02   ` Souza, Jose
2025-05-30  1:11   ` kernel test robot
2025-05-30  4:29   ` Matthew Brost
2025-05-27 16:40 ` [PATCH v3 18/19] drm/xe/bo: Add attributes field to xe_bo Himal Prasad Ghimiray
2025-05-28 23:47   ` Matthew Brost
2025-05-29  2:29     ` Ghimiray, Himal Prasad
2025-05-27 16:40 ` [PATCH v3 19/19] drm/xe/bo: Update atomic_access attribute on madvise Himal Prasad Ghimiray
2025-05-28 23:46   ` Matthew Brost
2025-05-29  3:03     ` Ghimiray, Himal Prasad
2025-05-29 18:24       ` Matthew Brost [this message]
2025-05-29 18:30         ` Matthew Brost
2025-05-27 21:35 ` ✓ CI.Patch_applied: success for MADVISE FOR XE Patchwork
2025-05-27 21:35 ` ✗ CI.checkpatch: warning " Patchwork
2025-05-27 21:37 ` ✓ CI.KUnit: success " Patchwork
2025-05-27 21:40 ` ✗ CI.Build: failure " Patchwork
2025-05-28  7:45 ` ✓ CI.Patch_applied: success " Patchwork
2025-05-28  7:45 ` ✗ CI.checkpatch: warning " Patchwork
2025-05-28  7:46 ` ✓ CI.KUnit: success " Patchwork
2025-05-28  7:50 ` ✗ CI.Build: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2025-05-29 18:52 [PATCH v3 05/19] drm/xe/vma: Modify new_vma to accept struct xe_vma_mem_attr as parameter kernel test robot
2025-06-02  6:19 ` Dan Carpenter
2025-05-29 23:18 [PATCH v3 09/19] drm/xe/svm: Split system allocator vma incase of madvise call kernel test robot
2025-06-02  6:31 ` Dan Carpenter

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=aDimXEhce5BUR7+J@lstrano-desk.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    /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.