Re: [i-g-t, v2] tests/intel/xe_exec_multi_queue: Check PXP is rejected on multi-queue

["Randhawa, Jagmeet" <jagmeet.randhawa@intel.com>]

On 7/16/2026 11:48 AM, Niranjana Vishwanathapura wrote:
> On Tue, Jul 14, 2026 at 03:05:37AM +0800, Jagmeet Randhawa wrote:
>> HWDRM is the only supported PXP type and is display related, so it
>> cannot be combined with a multi-queue exec queue group. Extend the
>> sanity subtest to create a multi-queue exec queue with the PXP HWDRM
>> property chained and verify the kernel rejects the combination.
>>
>> When PXP is supported the combination must fail with -EINVAL; when
>> PXP is unsupported the PXP extension fails first with -ENODEV.
>> The expected error is selected based on xe_wait_for_pxp_init(),
>> so the test passes on platforms with and without PXP.
>>
>
> Require 'v2: <changes done in v2>' tag.
> I think it is fine for now.
>
>> Signed-off-by: Jagmeet Randhawa <jagmeet.randhawa@intel.com>
>> ---
>> tests/intel/xe_exec_multi_queue.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/tests/intel/xe_exec_multi_queue.c 
>> b/tests/intel/xe_exec_multi_queue.c
>> index 9b41f87c7..6aa1fd5e4 100644
>> --- a/tests/intel/xe_exec_multi_queue.c
>> +++ b/tests/intel/xe_exec_multi_queue.c
>> @@ -65,6 +65,11 @@ __test_sanity(int fd, int gt, int class, bool 
>> preempt_mode)
>>         .property = DRM_XE_EXEC_QUEUE_SET_PROPERTY_PRIORITY,
>>         .value = XE_EXEC_QUEUE_PRIORITY_NORMAL,
>>     };
>> +    struct drm_xe_ext_set_property pxp_hwdrm = {
>> +        .base.name = DRM_XE_EXEC_QUEUE_EXTENSION_SET_PROPERTY,
>> +        .property = DRM_XE_EXEC_QUEUE_SET_PROPERTY_PXP_TYPE,
>> +        .value = DRM_XE_PXP_TYPE_HWDRM,
>> +    };
>>     struct drm_xe_engine_class_instance vm_bind_eci = {
>>         .engine_class = DRM_XE_ENGINE_CLASS_VM_BIND,
>>     };
>> @@ -119,6 +124,18 @@ __test_sanity(int fd, int gt, int class, bool 
>> preempt_mode)
>>     multi_queue.base.next_extension = to_user_pointer(&multi_queue);
>>     igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, eci, ext, 
>> &val), -EINVAL);
>>
>> +    /*
>> +     * HWDRM is the only supported PXP type and is display-related, 
>> so it
>> +     * cannot be combined with multi-queue. When PXP is supported 
>> the combo
>> +     * must be rejected with -EINVAL; when unsupported the PXP 
>> extension
>> +     * fails first with -ENODEV.
>> +     */
>
> NIT...Missing some commas.
>
> 'When PXP is supported, the combo must be...'
> and
> 'when unsupported, the PXP extension...'
>
> Also, when PXP is not supported, I don't think it will always return 
> -ENODEV.
> It depends on the order of the extensions (with new change in KMD patch).
> more below....
I will fix the description. Thanks
>
>> +    multi_queue.base.next_extension = to_user_pointer(&pxp_hwdrm);
>> +    if (xe_wait_for_pxp_init(fd) == 0)
>> +        igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, eci, ext, 
>> &val), -EINVAL);
>> +    else
>> +        igt_assert_eq(__xe_exec_queue_create(fd, vm, 1, 1, eci, ext, 
>> &val), -ENODEV);
>> +
>
> With KMD patch update, given order of properties is multi-queue first 
> followed by pxp,
> doesn't it should always return -EINVAL? We should get -ENODEV only 
> wehen the order of
> properties is PXP followed by multi-queue. Right?
>
> Niranjana
>
You are correct, This used to work with both branches because the 
original KMD patch had the check in exec_queue_user_ext_check_final(), 
which runs after all extensions are applied. Back then the PXP setter 
always ran first and could return -ENODEV on unsupported hardware before 
the final combo check. Moving the check earlier to bail out sooner, 
  changed that timing, so the test needs to follow suit. I will send v3 
  asserting -EINVAL unconditionally for this ordering since it is simpler.
>>     /* Setting other queue properties are valid for Q0 */
>>     multi_queue.base.next_extension = to_user_pointer(&priority);
>>     exec_queues[0] = xe_exec_queue_create(fd, vm, eci, ext);
>> -- 
>> 2.53.0
>>