[PATCH i-g-t] tests/intel/xe_sriov_flr: Handle missing provisioning data per-GT

[Bernatowicz, Marcin]

On 8/22/2025 11:47 AM, K V P, Satyanarayana wrote:
> 
> 
> On 22-08-2025 15:09, Marcin Bernatowicz wrote:
>> When reading provisioned LMEM ranges from debugfs, some GTs may not
>> expose provisioning data at all. Previously, this caused the test to
>> skip entirely with a "Failed read" reason.
>>
>> Relax the check to treat -ENOENT as a valid case and simply continue
>> to the next GT. This ensures the test is not skipped unnecessarily
>> when provisioning data is absent on some GTs.
>>
>> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz at linux.intel.com>
>> Cc: Adam Miszczak <adam.miszczak at linux.intel.com>
>> Cc: Jakub Kolakowski <jakub1.kolakowski at intel.com>
>> Cc: Lukasz Laguna <lukasz.laguna at intel.com>
>> Cc: Satyanarayana K V P <satyanarayana.k.v.p at intel.com>
>> ---
>>   tests/intel/xe_sriov_flr.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/tests/intel/xe_sriov_flr.c b/tests/intel/xe_sriov_flr.c
>> index fc08703c0..9eebe5f71 100644
>> --- a/tests/intel/xe_sriov_flr.c
>> +++ b/tests/intel/xe_sriov_flr.c
>> @@ -816,7 +816,9 @@ static int populate_vf_lmem_sizes(struct 
>> subcheck_data *data)
>>           ret = xe_sriov_pf_debugfs_read_provisioned_ranges(data->pf_fd,
>>                                     XE_SRIOV_SHARED_RES_LMEM,
>>                                     gt, &ranges, &nr_ranges);
> Is it applicable only for LMEM? What about other provisioning 
> parameters?> 

GGTT is already handled.

-        if (ret) {
>> +        if (ret == -ENOENT) {
>> +            continue;
> Can we add a debug level print here with GT id?> 

Something like: "No lmem_provisioned attribute on gt%u" ?



+        } else if (ret) {
>>               set_skip_reason(data, "Failed read %s on gt%u (%d)\n",
>>                       
>> xe_sriov_debugfs_provisioned_attr_name(XE_SRIOV_SHARED_RES_LMEM),
>>                       gt, ret);
>