From: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH v5 14/25] drm/xe/svm : Add svm ranges migration policy on atomic access
Date: Wed, 6 Aug 2025 10:59:40 +0530 [thread overview]
Message-ID: <39d17ad0-964f-4771-9cdf-bc65c53524c0@intel.com> (raw)
In-Reply-To: <aJJlPMHRsiQQmfNV@lstrano-desk.jf.intel.com>
On 06-08-2025 01:40, Matthew Brost wrote:
> On Wed, Jul 30, 2025 at 06:30:39PM +0530, Himal Prasad Ghimiray wrote:
>> If the platform does not support atomic access on system memory, and the
>> ranges are in system memory, but the user requires atomic accesses on
>> the VMA, then migrate the ranges to VRAM. Apply this policy for prefetch
>> operations as well.
>>
>> v2
>> - Drop unnecessary vm_dbg
>>
>> v3 (Matthew Brost)
>> - fix atomic policy
>> - prefetch shouldn't have any impact of atomic
>> - bo can be accessed from vma, avoid duplicate parameter
>>
>> v4 (Matthew Brost)
>> - Remove TODO comment
>> - Fix comment
>> - Dont allow gpu atomic ops when user is setting atomic attr as CPU
>>
>> v5 (Matthew Brost)
>> - Fix atomic checks
>> - Add userptr checks
>>
>> Cc: Matthew Brost <matthew.brost@intel.com>
>> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_pt.c | 23 ++++++++++--------
>> drivers/gpu/drm/xe/xe_svm.c | 8 ++++--
>> drivers/gpu/drm/xe/xe_vm.c | 39 ++++++++++++++++++++++++++++++
>> drivers/gpu/drm/xe/xe_vm.h | 2 ++
>> drivers/gpu/drm/xe/xe_vm_madvise.c | 15 +++++++++++-
>> 5 files changed, 74 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
>> index 593fef438cd8..6f5b384991cd 100644
>> --- a/drivers/gpu/drm/xe/xe_pt.c
>> +++ b/drivers/gpu/drm/xe/xe_pt.c
>> @@ -640,28 +640,31 @@ static const struct xe_pt_walk_ops xe_pt_stage_bind_ops = {
>> * - In all other cases device atomics will be disabled with AE=0 until an application
>> * request differently using a ioctl like madvise.
>> */
>> -static bool xe_atomic_for_vram(struct xe_vm *vm)
>> +static bool xe_atomic_for_vram(struct xe_vm *vm, struct xe_vma *vma)
>> {
>> + if (vma->attr.atomic_access == DRM_XE_ATOMIC_CPU)
>> + return false;
>> +
>> return true;
>> }
>>
>> -static bool xe_atomic_for_system(struct xe_vm *vm, struct xe_bo *bo)
>> +static bool xe_atomic_for_system(struct xe_vm *vm, struct xe_vma *vma)
>> {
>> struct xe_device *xe = vm->xe;
>> + struct xe_bo *bo = xe_vma_bo(vma);
>>
>> - if (!xe->info.has_device_atomics_on_smem)
>> + if (!xe->info.has_device_atomics_on_smem ||
>> + vma->attr.atomic_access == DRM_XE_ATOMIC_CPU)
>> return false;
>>
>> + if (vma->attr.atomic_access == DRM_XE_ATOMIC_DEVICE)
>> + return true;
>> +
>> /*
>> * If a SMEM+LMEM allocation is backed by SMEM, a device
>> * atomics will cause a gpu page fault and which then
>> * gets migrated to LMEM, bind such allocations with
>> * device atomics enabled.
>> - *
>> - * TODO: Revisit this. Perhaps add something like a
>> - * fault_on_atomics_in_system UAPI flag.
>> - * Note that this also prohibits GPU atomics in LR mode for
>> - * userptr and system memory on DGFX.
>> */
>> return (!IS_DGFX(xe) || (!xe_vm_in_lr_mode(vm) ||
>> (bo && xe_bo_has_single_placement(bo))));
>> @@ -744,8 +747,8 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
>> goto walk_pt;
>>
>> if (vma->gpuva.flags & XE_VMA_ATOMIC_PTE_BIT) {
>> - xe_walk.default_vram_pte = xe_atomic_for_vram(vm) ? XE_USM_PPGTT_PTE_AE : 0;
>> - xe_walk.default_system_pte = xe_atomic_for_system(vm, bo) ?
>> + xe_walk.default_vram_pte = xe_atomic_for_vram(vm, vma) ? XE_USM_PPGTT_PTE_AE : 0;
>> + xe_walk.default_system_pte = xe_atomic_for_system(vm, vma) ?
>> XE_USM_PPGTT_PTE_AE : 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
>> index 1d0b444bf2ae..5e78beebe114 100644
>> --- a/drivers/gpu/drm/xe/xe_svm.c
>> +++ b/drivers/gpu/drm/xe/xe_svm.c
>> @@ -793,14 +793,18 @@ int xe_svm_handle_pagefault(struct xe_vm *vm, struct xe_vma *vma,
>> struct xe_gt *gt, u64 fault_addr,
>> bool atomic)
>> {
>> + int need_vram = xe_vma_need_vram_for_atomic(vm->xe, vma, atomic);
>> +
>> + if (need_vram < 0)
>> + return need_vram;
>> +
>> struct drm_gpusvm_ctx ctx = {
>> .read_only = xe_vma_read_only(vma),
>> .devmem_possible = IS_DGFX(vm->xe) &&
>> IS_ENABLED(CONFIG_DRM_XE_PAGEMAP),
>> .check_pages_threshold = IS_DGFX(vm->xe) &&
>> IS_ENABLED(CONFIG_DRM_XE_PAGEMAP) ? SZ_64K : 0,
>> - .devmem_only = atomic && IS_DGFX(vm->xe) &&
>> - IS_ENABLED(CONFIG_DRM_XE_PAGEMAP),
>> + .devmem_only = need_vram && IS_ENABLED(CONFIG_DRM_XE_PAGEMAP),
>> .timeslice_ms = atomic && IS_DGFX(vm->xe) &&
>> IS_ENABLED(CONFIG_DRM_XE_PAGEMAP) ?
>> vm->xe->atomic_svm_timeslice_ms : 0,
>> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
>> index d039779412b3..463736db19d9 100644
>> --- a/drivers/gpu/drm/xe/xe_vm.c
>> +++ b/drivers/gpu/drm/xe/xe_vm.c
>> @@ -4183,6 +4183,45 @@ void xe_vm_snapshot_free(struct xe_vm_snapshot *snap)
>> kvfree(snap);
>> }
>>
>> +/**
>> + * xe_vma_need_vram_for_atomic - Check if VMA needs VRAM migration for atomic operations
>> + * @xe: Pointer to the XE device structure
>> + * @vma: Pointer to the virtual memory area (VMA) structure
>> + * @is_atomic: In pagefault path and atomic operation
>> + *
>> + * This function determines whether the given VMA needs to be migrated to
>> + * VRAM in order to do atomic GPU operation.
>> + *
>> + * Return:
>> + * 1 - Migration to VRAM is required
>> + * 0 - Migration is not required
>> + * -EINVAL - Invalid access for atomic memory attr
>
> Also how about -EACCES here?
>
> Matt
Sure
>
>> + *
>> + */
>> +int xe_vma_need_vram_for_atomic(struct xe_device *xe, struct xe_vma *vma, bool is_atomic)
>> +{
>> + if (!IS_DGFX(xe) || !is_atomic)
>> + return 0;
>> +
>> + /*
>> + * NOTE: The checks implemented here are platform-specific. For
>> + * instance, on a device supporting CXL atomics, these would ideally
>> + * work universally without additional handling.
>> + */
>> + switch (vma->attr.atomic_access) {
>> + case DRM_XE_ATOMIC_DEVICE:
>> + return !xe->info.has_device_atomics_on_smem;
>> +
>> + case DRM_XE_ATOMIC_CPU:
>> + return -EINVAL;
>> +
>> + case DRM_XE_ATOMIC_UNDEFINED:
>> + case DRM_XE_ATOMIC_GLOBAL:
>> + default:
>> + return 1;
>> + }
>> +}
>> +
>> /**
>> * xe_vm_alloc_madvise_vma - Allocate VMA's with madvise ops
>> * @vm: Pointer to the xe_vm structure
>> diff --git a/drivers/gpu/drm/xe/xe_vm.h b/drivers/gpu/drm/xe/xe_vm.h
>> index 0d6b08cc4163..05ac3118d9f4 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_vma_need_vram_for_atomic(struct xe_device *xe, struct xe_vma *vma, bool is_atomic);
>> +
>> int xe_vm_alloc_madvise_vma(struct xe_vm *vm, uint64_t addr, uint64_t size);
>>
>> /**
>> diff --git a/drivers/gpu/drm/xe/xe_vm_madvise.c b/drivers/gpu/drm/xe/xe_vm_madvise.c
>> index b861c3349b0a..a53b63dd603d 100644
>> --- a/drivers/gpu/drm/xe/xe_vm_madvise.c
>> +++ b/drivers/gpu/drm/xe/xe_vm_madvise.c
>> @@ -85,7 +85,20 @@ static void madvise_atomic(struct xe_device *xe, struct xe_vm *vm,
>> struct xe_vma **vmas, int num_vmas,
>> struct drm_xe_madvise *op)
>> {
>> - /* Implementation pending */
>> + int i;
>> +
>> + xe_assert(vm->xe, op->type == DRM_XE_MEM_RANGE_ATTR_ATOMIC);
>> + xe_assert(vm->xe, op->atomic.val <= DRM_XE_ATOMIC_CPU);
>> +
>> + for (i = 0; i < num_vmas; i++) {
>> + if (xe_vma_is_userptr(vmas[i])) {
>> + if (!(op->atomic.val == DRM_XE_ATOMIC_DEVICE &&
>> + xe->info.has_device_atomics_on_smem))
>> + continue;
>> + }
>> + vmas[i]->attr.atomic_access = op->atomic.val;
>> + /*TODO: handle bo backed vmas */
>> + }
>> }
>>
>> static void madvise_pat_index(struct xe_device *xe, struct xe_vm *vm,
>> --
>> 2.34.1
>>
next prev parent reply other threads:[~2025-08-06 5:29 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 13:00 [PATCH v5 00/25] MADVISE FOR XE Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 01/25] drm/gpuvm: Pass map arguments through a struct Himal Prasad Ghimiray
2025-07-30 23:23 ` kernel test robot
2025-08-05 3:56 ` Matthew Brost
2025-08-05 5:24 ` Ghimiray, Himal Prasad
2025-08-05 10:10 ` Danilo Krummrich
2025-08-05 11:04 ` Ghimiray, Himal Prasad
2025-08-05 9:40 ` Danilo Krummrich
2025-08-05 11:02 ` Ghimiray, Himal Prasad
2025-07-30 13:00 ` [PATCH v5 02/25] drm/gpuvm: Kill drm_gpuva_init() Himal Prasad Ghimiray
2025-08-05 3:45 ` Matthew Brost
2025-08-05 9:35 ` Danilo Krummrich
2025-07-30 13:00 ` [PATCH v5 03/25] drm/gpuvm: Support flags in drm_gpuva_op_map Himal Prasad Ghimiray
2025-08-05 3:58 ` Matthew Brost
2025-08-05 11:05 ` Ghimiray, Himal Prasad
2025-07-30 13:00 ` [PATCH v5 04/25] drm/gpuvm: Introduce DRM_GPUVM_SM_MAP_OPS_FLAG_SPLIT_MADVISE flag Himal Prasad Ghimiray
2025-08-05 19:24 ` Matthew Brost
2025-07-30 13:00 ` [PATCH v5 05/25] drm/xe/uapi: Add madvise interface Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 06/25] drm/xe/vm: Add attributes struct as member of vma Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 07/25] drm/xe/vma: Move pat_index to vma attributes Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 08/25] drm/xe/vma: Modify new_vma to accept struct xe_vma_mem_attr as parameter Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 09/25] drm/gpusvm: Make drm_gpusvm_for_each_* macros public Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 10/25] drm/xe/svm: Split system allocator vma incase of madvise call Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 11/25] drm/xe: Allow CPU address mirror VMA unbind with gpu bindings for madvise Himal Prasad Ghimiray
2025-08-05 4:00 ` Matthew Brost
2025-07-30 13:00 ` [PATCH v5 12/25] drm/xe/svm: Add xe_svm_ranges_zap_ptes_in_range() for PTE zapping Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 13/25] drm/xe: Implement madvise ioctl for xe Himal Prasad Ghimiray
2025-08-05 4:43 ` Matthew Brost
2025-07-30 13:00 ` [PATCH v5 14/25] drm/xe/svm : Add svm ranges migration policy on atomic access Himal Prasad Ghimiray
2025-08-05 20:03 ` Matthew Brost
2025-08-06 5:30 ` Ghimiray, Himal Prasad
2025-08-05 20:10 ` Matthew Brost
2025-08-06 5:29 ` Ghimiray, Himal Prasad [this message]
2025-07-30 13:00 ` [PATCH v5 15/25] drm/xe/madvise: Update migration policy based on preferred location Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 16/25] drm/xe/svm: Support DRM_XE_SVM_MEM_RANGE_ATTR_PAT memory attribute Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 17/25] drm/xe/uapi: Add flag for consulting madvise hints on svm prefetch Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 18/25] drm/xe/svm: Consult madvise preferred location in prefetch Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 19/25] drm/xe/bo: Add attributes field to xe_bo Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 20/25] drm/xe/bo: Update atomic_access attribute on madvise Himal Prasad Ghimiray
2025-08-05 20:06 ` Matthew Brost
2025-07-30 13:00 ` [PATCH v5 21/25] drm/xe/madvise: Skip vma invalidation if mem attr are unchanged Himal Prasad Ghimiray
2025-07-30 20:57 ` kernel test robot
2025-07-30 13:00 ` [PATCH v5 22/25] drm/xe/vm: Add helper to check for default VMA memory attributes Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 23/25] drm/xe: Reset VMA attributes to default in SVM garbage collector Himal Prasad Ghimiray
2025-08-06 4:06 ` Matthew Brost
2025-08-06 5:32 ` Ghimiray, Himal Prasad
2025-07-30 13:00 ` [PATCH v5 24/25] drm/xe: Enable madvise ioctl for xe Himal Prasad Ghimiray
2025-07-30 13:00 ` [PATCH v5 25/25] drm/xe/uapi: Add UAPI for querying VMA count and memory attributes Himal Prasad Ghimiray
2025-08-05 19:29 ` Matthew Brost
2025-07-30 14:20 ` ✗ CI.checkpatch: warning for MADVISE FOR XE (rev5) Patchwork
2025-07-30 14:21 ` ✓ CI.KUnit: success " Patchwork
2025-07-30 14:36 ` ✗ CI.checksparse: warning " Patchwork
2025-07-30 15:36 ` ✓ Xe.CI.BAT: success " Patchwork
2025-07-30 17:51 ` ✗ Xe.CI.Full: 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=39d17ad0-964f-4771-9cdf-bc65c53524c0@intel.com \
--to=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=thomas.hellstrom@linux.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