[PATCH i-g-t 2/2] xe_live_ktest: Use xe_live_test kernel module

[Janusz Krzysztofik]

On Wednesday, 7 February 2024 18:26:53 CET Lucas De Marchi wrote:
> On Wed, Feb 07, 2024 at 12:27:48PM +0100, Janusz Krzysztofik wrote:
> >On Friday, 2 February 2024 01:45:29 CET Lucas De Marchi wrote:
> >> https://patchwork.freedesktop.org/series/126786/ groups all the live
> >> tests into a single kernel module. Use that module to run any of the
> >> tests triggered by igt.
> >>
> >> To make the live kunit tests work, rename the subtests so they match
> >> what the kernel uses.
> >
> >There was some discussion on this patch on today's XE IGT status meeting, 
and
> >the conclusion was: can we have these split into two patches, one for 
subtest
> >renaming, and one for switching to single module?
> 
> that would break the test. Wouldn't it make more sense to squash the
> subtest rename in your series since it's changing the logic
> for filtering (https://lore.kernel.org/igt-dev/2202702.NgBsaNRSFp@jkrzyszt-mobl2.ger.corp.intel.com/)

The rename part can be applied immediately, I believe.  Looking at current CI 
results we can see 2 cases:

1. If the test successfully (re)loads the KUnit base module in list only mode 
(e.g. after xe and its dependencies, including kunit, were unloaded by a 
preceding test) and that is followed by successful load of a xe kunit test 
module then the test is no longer able to reload the base kunit module in exec 
mode and skips.  Renaming the subtests won't change that.

2. If the test finds the xe module and its dependencies, including kunit, 
already loaded then it can't reload the kunit module in list mode and falls 
back to the legacy processing path.  That path works, i.e., returns results 
from test cases as results from IGT dynamic sub-subtests, even if subtest name 
doesn't match suite name.

Then, renaming subtests even before my series is finally accepted and applied 
won't break anything.

Thanks,
Janusz

> 
> If we squash the subtest renaming there and leave the module rename
> here, then we don't break anything (although this part here needs to
> land with the kernel side too).
> 
> Lucas De Marchi
>