All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Brost <matthew.brost@intel.com>
To: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v3 09/19] drm/xe/svm: Split system allocator vma incase of madvise call
Date: Wed, 28 May 2025 19:49:21 -0700	[thread overview]
Message-ID: <aDfLMTBTEsxVLO6C@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20250527164003.1068118-10-himal.prasad.ghimiray@intel.com>

On Tue, May 27, 2025 at 10:09:53PM +0530, Himal Prasad Ghimiray wrote:
> If the start or end of input address range lies within system allocator
> vma split the vma to create new vma's as per input range.
> 
> v2 (Matthew Brost)
> - Add lockdep_assert_write for vm->lock
> - Remove unnecessary page aligned checks
> - Add kerrnel-doc and comments
> - Remove unnecessary unwind_ops and return
> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_vm.c | 95 ++++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/xe/xe_vm.h |  2 +
>  2 files changed, 97 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index d60b711e97e9..c220bf904ee0 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -4161,3 +4161,98 @@ void xe_vm_snapshot_free(struct xe_vm_snapshot *snap)
>  	}
>  	kvfree(snap);
>  }
> +
> +/**
> + * xe_vm_alloc_madvise_vma - Allocate VMA's with madvise ops
> + * @vm: Pointer to the xe_vm structure
> + * @start: Starting input address
> + * @range: Size of the input range
> + *
> + * This function splits existing vma to create new vma for user provided input range
> + *
> + *  Return: 0 if success
> + */
> +int xe_vm_alloc_madvise_vma(struct xe_vm *vm, uint64_t start, uint64_t range)
> +{
> +	struct xe_vma_ops vops;
> +	struct drm_gpuva_ops *ops = NULL;
> +	struct drm_gpuva_op *__op;
> +	bool is_cpu_addr_mirror = false;
> +	int err;
> +
> +	vm_dbg(&vm->xe->drm, "MADVISE IN: addr=0x%016llx, size=0x%016llx", start, range);
> +
> +	lockdep_assert_held_write(&vm->lock);
> +
> +	vm_dbg(&vm->xe->drm, "MADVISE_OPS_CREATE: addr=0x%016llx, size=0x%016llx", start, range);
> +	ops = drm_gpuvm_sm_map_ops_create(&vm->gpuvm, start, range,
> +					  DRM_GPUVM_SKIP_GEM_OBJ_VA_SPLIT_MADVISE,
> +					  NULL, start);
> +	if (IS_ERR(ops))
> +		return PTR_ERR(ops);
> +
> +	if (list_empty(&ops->list)) {
> +		err = 0;
> +		goto free_ops;
> +	}
> +
> +	drm_gpuva_for_each_op(__op, ops) {
> +		struct xe_vma_op *op = gpuva_op_to_vma_op(__op);
> +
> +		if (__op->op == DRM_GPUVA_OP_REMAP) {
> +			if (xe_vma_is_cpu_addr_mirror(gpuva_to_vma(op->base.remap.unmap->va)))
> +				is_cpu_addr_mirror = true;
> +			else
> +				is_cpu_addr_mirror = false;

Maybe let's add a sanity check here to make sure we know what we are
doing.

			xe_assert(xe, !remap_op);
			remap_op = true;
> +		}
> +
> +		if (__op->op == DRM_GPUVA_OP_MAP)
> +			/* In case of madvise ops DRM_GPUVA_OP_REMAP is always by
> +			 * DRM_GPUVA_OP_REMAP, so ensure we assign op->map.is_cpu_addr_mirror true
> +			 * if REMAP is for xe_vma_is_cpu_addr_mirror vma
> +			 */
> +			op->map.is_cpu_addr_mirror = is_cpu_addr_mirror;

			xe_assert(xe, remap_op);

> +
> +		print_op(vm->xe, __op);
> +	}
> +
> +	xe_vma_ops_init(&vops, vm, NULL, NULL, 0);
> +	err = vm_bind_ioctl_ops_parse(vm, ops, &vops);
> +	if (err)
> +		goto unwind_ops;
> +
> +	xe_vm_lock(vm, false);
> +
> +	drm_gpuva_for_each_op(__op, ops) {
> +		struct xe_vma_op *op = gpuva_op_to_vma_op(__op);
> +		struct xe_vma *vma;
> +		struct xe_vma_mem_attr temp_attr;
> +
> +		if (__op->op == DRM_GPUVA_OP_UNMAP) {
> +			/* There should be no unmap */
> +			XE_WARN_ON("UNEXPECTED UNMAP");
> +			xe_vma_destroy(gpuva_to_vma(op->base.unmap.va), NULL);
> +		} else if (__op->op == DRM_GPUVA_OP_REMAP) {
> +			vma = gpuva_to_vma(op->base.remap.unmap->va);
> +			/* Store attributes for REMAP UNMAPPED VMA, so they can be assigned
> +			 * to newly MAPPED vma.
> +			 */
> +			cp_vma_mem_attr(&temp_attr, &vma->attr);

Again maybe drop the helper here.

> +			xe_vma_destroy(gpuva_to_vma(op->base.remap.unmap->va), NULL);
> +		} else if (__op->op == DRM_GPUVA_OP_MAP) {
> +			vma = op->map.vma;
> +			cp_vma_mem_attr(&vma->attr, &temp_attr);

And here.

With the nits fixed:
Reviewed-by: Matthew Brost <matthew.brost@intel.com>

> +		}
> +	}
> +
> +	xe_vm_unlock(vm);
> +	drm_gpuva_ops_free(&vm->gpuvm, ops);
> +	return 0;
> +
> +unwind_ops:
> +	vm_bind_ioctl_ops_unwind(vm, &ops, 1);
> +free_ops:
> +	if (ops)
> +		drm_gpuva_ops_free(&vm->gpuvm, ops);
> +	return err;
> +}
> diff --git a/drivers/gpu/drm/xe/xe_vm.h b/drivers/gpu/drm/xe/xe_vm.h
> index 1ef98113fa5b..8151b1b01a13 100644
> --- a/drivers/gpu/drm/xe/xe_vm.h
> +++ b/drivers/gpu/drm/xe/xe_vm.h
> @@ -171,6 +171,8 @@ static inline bool xe_vma_is_userptr(struct xe_vma *vma)
>  
>  struct xe_vma *xe_vm_find_vma_by_addr(struct xe_vm *vm, u64 page_addr);
>  
> +int xe_vm_alloc_madvise_vma(struct xe_vm *vm, uint64_t addr, uint64_t size);
> +
>  /**
>   * to_userptr_vma() - Return a pointer to an embedding userptr vma
>   * @vma: Pointer to the embedded struct xe_vma
> -- 
> 2.34.1
> 

  reply	other threads:[~2025-05-29  2:48 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 [this message]
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
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=aDfLMTBTEsxVLO6C@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.