Re: [PATCH] xe_exec_system_allocator: fix MADVISE_MULTI_VMA and PREFETCH_SAME_ATTR bo_size for PVC

"Sharma, Nishit" <[email protected]> Tue, 4 Aug 2026 09:56:36 +0530
Newsgroups org.freedesktop.lists.igt-dev
Message-ID <[email protected]>
On 8/4/2026 2:55 AM, Jia Yao wrote:
> Both flags split the buffer in half with madvise, creating a bo_size/2
> VMA fragment.  On PVC (NEED64K) drm_gpusvm requires chunks >= 64K, so
> with bo_size=SZ_64K the 32K fragment causes -EINVAL, a GPU CAT error
> and EIO from xe_wait_ufence.
>
> Add both flags to the existing SZ_128K condition so each half is exactly
> 64K on NEED64K platforms.
>
> Fixes: 022265cb9ebcb199 ("xe_exec_system_allocator: fix PREFETCH_SPLIT_VMA bo_size for PVC")
> Cc: Nishit Sharma <[email protected]>
> Signed-off-by: Jia Yao <[email protected]>
> ---
>   tests/intel/xe_exec_system_allocator.c | 12 +++++++++++-
>   1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/tests/intel/xe_exec_system_allocator.c b/tests/intel/xe_exec_system_allocator.c
> index 50cd6ead7..6ca53aa5f 100644
> --- a/tests/intel/xe_exec_system_allocator.c
> +++ b/tests/intel/xe_exec_system_allocator.c
> @@ -2814,8 +2814,18 @@ int igt_main()
>   				 * and migrates the first half. On platforms with
>   				 * 64K VRAM granularity (e.g. PVC), each half
>   				 * must be >= 64K, so use SZ_128K as bo_size.
> +				 *
> +				 * MADVISE_MULTI_VMA applies madvise on
> +				 * data+bo_size/2 for bo_size/2 bytes, and
> +				 * PREFETCH_SAME_ATTR applies madvise on data
> +				 * for bo_size/2 bytes after a full-buffer
> +				 * prefetch.  Both create a bo_size/2 VMA
> +				 * fragment; on NEED64K platforms that fragment
> +				 * must be >= 64K, so use SZ_128K for them too.
>   				 */
> -				size_t bo_size = (s->flags & PREFETCH_SPLIT_VMA) ?
> +				size_t bo_size = (s->flags & (PREFETCH_SPLIT_VMA |
> +							      MADVISE_MULTI_VMA |
> +							      PREFETCH_SAME_ATTR)) ?
>   						 SZ_128K : SZ_64K;
>   
>   				test_exec(fd, hwe, 1, 1, bo_size, 0, 0, NULL,

LGTM:

Reviewed-by: Nishit Sharma <[email protected]>