Re: [PATCH 1/2] drm/xe/migrate: Keep access_memory chunks within the transfer limit

[Matthew Auld <matthew.auld@intel.com>]

On 27/10/2026 14:52, Mika Kuoppala wrote:
> xe_migrate_access_memory() caps each chunk at MAX_PREEMPTDISABLE_TRANSFER,
> but xe_migrate_vram() maps the system memory side from the start of the
> page the chunk begins in, DIV_ROUND_UP(len + sram_offset, PAGE_SIZE)
> pages.
> 
> So when buf is mid page, the 'wasted' space at the start of the first
> page needs to be taken into account when considering the amount that
> can be copied. Otherwise a full chunk needs one page more than the limit
> allows, which trips the warning in pte_update_cmd_size() and, on debug
> builds, the assert in xe_migrate_vram().
> 
> window:  |slot 0|slot 1| ...  |slot 2047|
>           0                              8M
> data:      [=================================]   starts at sram_offset
>             ^ sram_offset                ^ must end here or earlier
> 
> This happens for example when the access starts at an unaligned vram
> offset.
> 
> Fix this by capping the chunk at the limit minus sram_offset.
> 
> Seen on BMG with igt@xe_eudebug@vm-access-alignment, which rewrites 24M
> and 48M objects from offset 4 through eudebug vm access:
> 
>    xe 0000:03:00.0: [drm] Assertion `npages * ((1UL) << 12) <= 0x00800000` failed!
>    WARNING: drivers/gpu/drm/xe/xe_migrate.c:2255 at xe_migrate_vram+0xf40/0x15e0 [xe]
>    Call Trace:
>    xe_migrate_access_memory
>    xe_ttm_access_memory
>    ttm_bo_access
> 
>    WARNING: drivers/gpu/drm/xe/xe_migrate.c:2118 at xe_migrate_vram+0xbb7/0x15e0 [xe]
>    Call Trace:
>    xe_migrate_access_memory
>    xe_ttm_access_memory
>    ttm_bo_access
> 
> Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU for non-visible access")
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Jan Maslak <jan.maslak@intel.com>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

Reviewed-by: Matthew Auld <matthew.auld@intel.com>