[PATCH i-g-t] tests/intel/xe_exec_reset: Add mocs reset test

[Matt Roper]

On Mon, Oct 28, 2024 at 04:17:48PM +0530, janga.rahul.kumar at intel.com wrote:
> From: Janga Rahul Kumar <janga.rahul.kumar at intel.com>
> 
> Check mocs configuration over GT reset.
> 
> Signed-off-by: Janga Rahul Kumar <janga.rahul.kumar at intel.com>
> ---
>  tests/intel/xe_exec_reset.c | 35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/tests/intel/xe_exec_reset.c b/tests/intel/xe_exec_reset.c
> index 43ef1e334..f4129dbd7 100644
> --- a/tests/intel/xe_exec_reset.c
> +++ b/tests/intel/xe_exec_reset.c
> @@ -715,6 +715,37 @@ gt_reset(int fd, int n_threads, int n_sec)
>  	free(threads);
>  }
>  
> +/**
> + * SUBTEST: gt-mocs-reset
> + * Description: Validate mocs register contents over GT reset
> + * Test category: mocs
> + * Functionality: mocs
> + *
> + */
> +static void
> +gt_mocs_reset(int fd, int gt)
> +{
> +	char path[256];
> +
> +	// Mocs debugfs contents before and after suspend-resume
> +	char mocs_content_pre[4096], mocs_contents_post[4096];

These are pretty big to be allocating on the stack.  But I'm also not
sure if they're large enough to hold the complete data on all platforms?
I didn't calculate exactly, but for Xe_LP platforms we have 64 MOCS
entries and the debugfs has data for both the global mocs table and the
lncf mocs table.  So about 128 lines of data; the LNCF lines are 40-ish
characters and the GLOBMOCS lines are 80-ish characters.  That's already
over 7500 bytes of output, without accounting for a few extra
miscellaneous lines of output.


> +
> +	sprintf(path, "gt%d/mocs", gt);
> +	igt_assert(igt_debugfs_exists(fd, path, O_RDONLY));
> +	igt_debugfs_dump(fd, path);
> +	igt_debugfs_read(fd, path, mocs_content_pre);
> +
> +	xe_force_gt_reset_sync(fd, gt);
> +	usleep(250000); /* 250 ms */

Why do we need this usleep()?  Isn't the point of using the _sync form
of the reset that we expect the reset to be complete at this point
without further waiting?

In general relying on magic sleeps like this in IGT tests causes us a
lot of headaches down the road.  A delay might look long enough in
normal usage, but once we start running tests in certain kinds of debug,
highly-instrumented environments it sometimes slows things down enough
that we find whatever number we picked isn't always long enough.  We
should always try to wait for true completion of an action rather "this
is hopefully long enough" delays.


Matt

> +
> +	igt_assert(igt_debugfs_exists(fd, path, O_RDONLY));
> +	igt_debugfs_dump(fd, path);
> +	igt_debugfs_read(fd, path, mocs_contents_post);
> +
> +	igt_assert(strcmp(mocs_content_pre, mocs_contents_post) == 0);
> +
> +}
> +
>  igt_main
>  {
>  	struct drm_xe_engine_class_instance *hwe;
> @@ -820,6 +851,10 @@ igt_main
>  	igt_subtest("gt-reset-stress")
>  		gt_reset(fd, 4, 1);
>  
> +	igt_subtest("gt-mocs-reset")
> +		xe_for_each_gt(fd, gt)
> +			gt_mocs_reset(fd, gt);
> +
>  	igt_fixture
>  		drm_close_driver(fd);
>  }
> -- 
> 2.25.1
> 

-- 
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation