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

[Bernatowicz, Marcin]

On 8/22/2025 3:00 PM, Michal Wajdeczko wrote:
> 
> 
> On 8/22/2025 2:48 PM, K V P, Satyanarayana wrote:
>>
>>
>> On 22-08-2025 15:51, Bernatowicz, Marcin wrote:
>>>
>>>
>>> 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" ?
>>>
>> Yes. With adding this debug print,
> 
> IMO we shouldn't even try to read LMEM provisioning from media GTs,
> as today it is exposed on primary GT (gt0) only, and this is just due
> to some early xe debugfs limitations, as there was no tile concept there,
> but since it was added recently, in the (near) future we might want to expose
> LMEM directly under Tile only (tile0), but definitely never under media GT
> 
> and without that call, there will be no need to handle expected error nor
> print a little misleading debug message (as it's not about missing attribute)

Thanks Michal, makes sense. For now I can limit the iteration to only 
root/primary GTs, that should avoid hitting the -ENOENT path and keep
the debug logs cleaner.

I don’t see a tile-level query in the API today – only queries for GTs
which also report their tile_id. Anyway, we’ll follow up with a separate
patch to adjust the helpers for the new tileX/gtY/[pf|vfZ] layout.

> 
>> Reviewed-by: Satyanarayana K V P <satyanarayana.k.v.p at intel.com>
>>
>>>
>>>
>>> +        } 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);
>>>>
>>>
>>
>