[PATCH i-g-t] tests/intel-ci/xe-sriov-vf.blocklist.txt: Blocklist for SR-IOV VF BAT runs

[Bernatowicz, Marcin]

On 7/18/2024 12:37 PM, Michal Wajdeczko wrote:
> 
> 
> On 17.07.2024 17:30, Marcin Bernatowicz wrote:
>> Blocklist tests not applicable for Virtual Function (VF) BAT runs.
> 
> is this 'VF BAT run' about running IGTs in VM, or it's something different?
> 
it's about running BAT tests on VF device not in VM

>> The list extends xe.blocklist.txt to enable xe-fast-feedback.testlist
>> execution on VF device.
> 
> maybe it's just a outdated doc, but README [1] says that blocklist is
> only applied to *FULL* not *BAT* runs:
> 
> "blacklist.txt
> 
> This file contains regular expressions (one per line) for tests that are
> not to be executed in full suite test rounds."
> 
> [1]
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/tests/intel-ci/README?ref_type=heads
> 
looks outdated doc
>>
>> Cc: Adam Miszczak <adam.miszczak at linux.intel.com>
>> Cc: Lukasz Laguna <lukasz.laguna at intel.com>
>> Cc: Jakub Kolakowski <jakub1.kolakowski at intel.com>
>> Cc: Michal Wajdeczko <Michal.Wajdeczko at intel.com>
>> Cc: Kamil Konieczny <kamil.konieczny at linux.intel.com>
>> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz at linux.intel.com>
>> ---
>>   tests/intel-ci/meson.build               |  1 +
>>   tests/intel-ci/xe-sriov-vf.blocklist.txt | 21 +++++++++++++++++++++
>>   2 files changed, 22 insertions(+)
>>   create mode 100644 tests/intel-ci/xe-sriov-vf.blocklist.txt
>>
>> diff --git a/tests/intel-ci/meson.build b/tests/intel-ci/meson.build
>> index f16243cbb..59323eda9 100644
>> --- a/tests/intel-ci/meson.build
>> +++ b/tests/intel-ci/meson.build
>> @@ -11,6 +11,7 @@ intelci_files = [
>>     'xe.blocklist.txt',
>>     'xe-fast-feedback.testlist',
>>     'xe-fast-feedback-chamelium-only.testlist',
>> +  'xe-sriov-vf.blocklist.txt',
>>   ]
>>   
>>   install_data(sources : intelci_files, install_dir : datadir)
>> diff --git a/tests/intel-ci/xe-sriov-vf.blocklist.txt b/tests/intel-ci/xe-sriov-vf.blocklist.txt
>> new file mode 100644
>> index 000000000..dae20bc6c
>> --- /dev/null
>> +++ b/tests/intel-ci/xe-sriov-vf.blocklist.txt
> 
> not a CI expert, but if there is:
> 
> 	xe-fast-feedback.testlist
> 
> then maybe corresponding blocklist should be named:
> 
> 	xe-fast-feedback.vf.blocklist
> 
> (and btw, I'm wondering why blocklists have .txt extension while
> testlists correctly don't have it)
> 
kept naming after xe.blocklist.txt
> 
> 
>> @@ -0,0 +1,21 @@
>> +##################################################################
>> +# Block list for VF xe-fast-feedback runs
>> +##################################################################
>> +# The module is already loaded when VF is created
>> +##################################################################
>> +igt at xe_module_load
> 
> if tests are executed inside the VM then testing a module reload is
> something that we want to have, no?

tests are executed on VF device not inside VM
> 
>> +##################################################################
>> +# Not applicable on VF
>> +##################################################################
>> +igt at fbdev
> 
> some devices don't have display (like ATSM) and likely don't have
> dedicated .blocklist for them, so maybe it's fine that these tests will
> SKIP (unless there will be separate BAT.display run introduced, where we
> can also run kms tests)

blocked as currently skips on all platforms with SR-IOV enabled
> 
>> +igt at sriov_basic
>> +igt at kms.*
>> +igt at xe_gt_freq
>> +igt at xe_live_ktest
> 
> only individual live-testcases might be N/A for VFs, but in general we
> want to be able to execute live-tests on the VF
> 
> see [2] how this will be improved soon
> 
> [2] https://patchwork.freedesktop.org/patch/604990/?series=136163&rev=2

will look at it
> 
>> +igt at xe_pm_residency
>> +##################################################################
>> +# Under investigation
> 
> what does it mean?
> is it broken test or broken VF driver?
> do we track those failures anywhere?

may be both, we want to start with clean execution first
failures are internally tracked at the moment
> 
>> +##################################################################
>> +igt at xe_debugfs@gt
>> +igt at xe_evict_ccs@evict-overcommit-simple
>> +igt at xe_evict_ccs@evict-overcommit-parallel-nofree-samefd