Zero-initialize the entire test_result structure used by memslot_perf_test
instead of zeroing only the fields used to guard the pr_info() calls.

gcc 13.2.0 is a bit overzealous and incorrectly thinks that rbestslottime's
slot_runtime may be used uninitialized.

  In file included from memslot_perf_test.c:25:
  memslot_perf_test.c: In function ‘main’:
  include/test_util.h:31:22: error: ‘rbestslottime.slot_runtime.tv_nsec’ may be used uninitialized [-Werror=maybe-uninitialized]
     31 | #define pr_info(...) printf(__VA_ARGS__)
        |                      ^~~~~~~~~~~~~~~~~~~
  memslot_perf_test.c:1127:17: note: in expansion of macro ‘pr_info’
   1127 |                 pr_info("Best slot setup time for the whole test area was %ld.%.9lds\n",
        |                 ^~~~~~~
  memslot_perf_test.c:1092:28: note: ‘rbestslottime.slot_runtime.tv_nsec’ was declared here
   1092 |         struct test_result rbestslottime;
        |                            ^~~~~~~~~~~~~
  include/test_util.h:31:22: error: ‘rbestslottime.slot_runtime.tv_sec’ may be used uninitialized [-Werror=maybe-uninitialized]
     31 | #define pr_info(...) printf(__VA_ARGS__)
        |                      ^~~~~~~~~~~~~~~~~~~
  memslot_perf_test.c:1127:17: note: in expansion of macro ‘pr_info’
   1127 |                 pr_info("Best slot setup time for the whole test area was %ld.%.9lds\n",
        |                 ^~~~~~~
  memslot_perf_test.c:1092:28: note: ‘rbestslottime.slot_runtime.tv_sec’ was declared here
   1092 |         struct test_result rbestslottime;
        |                            ^~~~~~~~~~~~~

That can't actually happen, at least not without the "result" structure in
test_loop() also being used uninitialized, which gcc doesn't complain
about, as writes to rbestslottime are all-or-nothing, i.e. slottimens can't
be non-zero without slot_runtime being written.

	if (!data->mem_size &&
	    (!rbestslottime->slottimens ||
	     result.slottimens < rbestslottime->slottimens))
		*rbestslottime = result;

Zero-initialize the structures to make gcc happy even though this is
likely a compiler bug.  The cost to do so is negligible, both in terms of
code and runtime overhead.  The only downside is that the compiler won't
warn about legitimate usage of "uninitialized" data, e.g. the test could
end up consuming zeros instead of useful data.  However, given that the
test is quite mature and unlikely to see substantial changes, the odds of
introducing such bugs are relatively low, whereas being able to compile
KVM selftests with -Werror detects issues on a regular basis.
Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Link: https://lore.kernel.org/r/20231005002954.2887098-1-seanjc@google.comSigned-off-by: Sean Christopherson <seanjc@google.com>