Re: [CI] HAX: Try SR-IOV on ADLP/ATSM

[Michal Wajdeczko <michal.wajdeczko@intel.com>]

On 28.06.2024 22:58, Lucas De Marchi wrote:
> On Fri, Jun 28, 2024 at 10:22:07PM GMT, Michal Wajdeczko wrote:
>>
>>
>> On 28.06.2024 20:51, Rodrigo Vivi wrote:
>>> On Mon, Jun 24, 2024 at 02:02:03PM +0200, Michal Wajdeczko wrote:
>>>> This is for CI only. DO NOT REVIEW. DO NOT MERGE.
>>>
>>> how are these tests looking like at this moment?
>>
>> IMO quite good
> `
> can you list all the tests are covering the sriov enabling?

from what I can see from the results [1] below, we have:

* sriov_basic@enable-vfs-autoprobe-off, see [5]

test will validate whether the PF is able to configure VFs (in
auto-provisioning mode) and then enable any number of supported VFs,
from 1 VF to 7 or more VFs, without actually loading the VF drivers

* sriov_basic@enable-vfs-autoprobe-on, see [6]

like above, but all VF drivers will be loaded automatically by the PCI
subsystem (could be treated as stress-test)

* sriov_basic@bind-unbind-vf, see [7]

like above, but each VF driver will be loaded separately by the test

* igt@sriov_basic@enable-vfs-bind-unbind-each

like above, but each VF driver will be loaded and then unloaded
separately by the test (it should be less stress-full)


+ Lukasz who can tell more about the plans for full SR-IOV validation


[5]
https://intel-gfx-ci.01.org/tree/intel-xe/igt@sriov_basic@enable-vfs-autoprobe-off.html

[6]
https://intel-gfx-ci.01.org/tree/intel-xe/igt@sriov_basic@enable-vfs-autoprobe-on.html

[7]
https://intel-gfx-ci.01.org/tree/intel-xe/igt@sriov_basic@bind-unbind-vf.html

[8]
https://intel-gfx-ci.01.org/tree/intel-xe/igt@sriov_basic@enable-vfs-bind-unbind-each.html

> 
> Also it'd be good to have an "admin guide" to use it.

at the moment we would like to rely only on the default VFs
configurations, aka auto-provisioning, so to enable or disable the VFs
we should only use existing mechanism exposed by the PCI subsystem
attribute 'sriov_numvfs', described in [9]

once we have VF devices enabled, we can use them almost as any other PCI
device, including running IGT tests, where we can specify target device:

	--device pci:slot=0000:4d:00.1

where 0000:4d:00.1 is BDF of the VF1

our experimental/advanced knobs to prepare custom VF configurations,
exposed by the PF driver over debugfs [10], should be used with care and
currently are only aimed for debug/tuning purposes

[9]
https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-pci#L302

[10]
https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/xe/xe_gt_sriov_pf_debugfs.c

> 
>>
>> recent run [1] just uncovered two existing issues that actually are not
>> related to the Xe SR-IOV code:
>>
>> first problem [2]:
>>
>> Starting dynamic subtest: vf-2
>> (sriov_basic:1395) igt_device-WARNING: Couldn't find PCI device
>> 0000:00:02:02
>>
>> was due to a test bug, attempt to fix that is under review [3]
>>
>>
>> second problem [4]:
>>
>> <7> [259.552619] BUG: MAX_LOCKDEP_KEYS too low!
>> <7> [259.552626] turning off the locking correctness validator.
>>
>> was reproduced on driver running in non-SRIOV mode (native), not sure
>> whether public bug was created for it, though
>>
>>
>> [1]
>> https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-135295v2/index.html?testfilter=iov
>>
>> [2]
>> https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-135295v2/shard-adlp-2/igt@sriov_basic@bind-unbind-vf.html
>>
>> [3] https://patchwork.freedesktop.org/series/135476/
>>
>> [4]
>> https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-135295v2/shard-adlp-1/igt@sriov_basic@enable-vfs-autoprobe-on.html#dmesg-warnings1677
>>
>>
>>> I'm wondering if it is already time to add this patch to topic/xe-for-CI
>>
>> it would be great, as this patch allows running few basic SR-IOV tests
>> (including VF driver probe) on the existing BAT/FULL CI runs, so with
>> minimal effort we will be able to catch regressions/breaks that impacts
>> the VF driver.
>>
>> note that being a PF driver by default shouldn't impact any existing
>> results or functionality, as any resources needed for VFs are reserved
>> only when VFs are enable during the SR-IOV tests.
>>
>> additional resources used by the PF until VF are enabled are negligible
>>
>>>
>>> Thomas? Lucas? thoughts?
> 
> 
> //  Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
> 
> on merging to topic/xe-for-CI branch.
> 
> thanks
> Lucas De Marchi