[Intel-gfx] [PATCH i-g-t 3/4] hw-tests: Fix and update gem_bad_address

Chris Wilson chris at chris-wilson.co.uk
Fri Dec 15 20:46:49 UTC 2017


Quoting Petri Latvala (2017-12-13 12:58:15)
> From: Antonio Argenziano <antonio.argenziano at intel.com>
> 
> When writing to an invalid memory location, the HW should be clever
> enough to silently discard the write without disrupting execution.
> gem_bad_address aim at just that. The test has been updated to move away
> from the libDrm wrappers and use the IOCTL wrappers instead. Also the
> invalid address has been updated to be just outside of the GTT space.

It barely scratch the surfaces of what could be done to feed in a bad
address.

> 
> v2 (Petri): Split the directory changes to separate commits, fix
> indentation
> 
> Signed-off-by: Antonio Argenziano <antonio.argenziano at intel.com>
> Signed-off-by: Petri Latvala <petri.latvala at intel.com>
> ---
>  tests/hw-tests/gem_bad_address.c | 69 +++++++++++++++++++++++-----------------
>  1 file changed, 39 insertions(+), 30 deletions(-)
> 
> diff --git a/tests/hw-tests/gem_bad_address.c b/tests/hw-tests/gem_bad_address.c
> index a970dfa4..2d6112bd 100644
> --- a/tests/hw-tests/gem_bad_address.c
> +++ b/tests/hw-tests/gem_bad_address.c
> @@ -23,37 +23,53 @@
>   * Authors:
>   *    Eric Anholt <eric at anholt.net>
>   *    Jesse Barnes <jbarnes at virtuousgeek.org> (based on gem_bad_blit.c)
> + *    Antonio Argenziano <antonio.argenziano at intel.com>
>   *
>   */
>  
>  #include "igt.h"
> -#include <stdlib.h>
> -#include <stdio.h>
> -#include <string.h>
> -#include <fcntl.h>
> -#include <inttypes.h>
> -#include <errno.h>
> -#include <sys/stat.h>
> -#include <sys/time.h>
> -#include "drm.h"
> -#include "intel_bufmgr.h"
>  
> -static drm_intel_bufmgr *bufmgr;
> -struct intel_batchbuffer *batch;
> -
> -#define BAD_GTT_DEST ((512*1024*1024)) /* past end of aperture */
> +/*
> + * This test aims at verifying that writing to an invalid location in memory,
> + * doesn't cause hangs. The store command should be ignored completely by the
> + * HW and the whole process should be transparent to the user. Therefore,
> + * the test doesn't perform any validation check but expects the wrapping
> + * execution environment to check no hangs have occurred.

igt provides the facilities to detect GPU hangs. Wrap in
igt_fork_hang_detector, finish with gem_sync. Actual machine death sadly
requires an outside body.

> + *
> + * The test needs to send a privileged batch to be able to write to the GTT.
> + */
>  
>  static void
> -bad_store(void)
> +bad_store(uint32_t fd, uint32_t engine)
>  {
> -       BEGIN_BATCH(4, 0);
> -       OUT_BATCH(MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL | 1 << 21);
> -       OUT_BATCH(0);
> -       OUT_BATCH(BAD_GTT_DEST);
> -       OUT_BATCH(0xdeadbeef);
> -       ADVANCE_BATCH();
> +       struct drm_i915_gem_exec_object2 obj;
> +       struct drm_i915_gem_execbuffer2 execbuf;
> +
> +       uint32_t batch[16];
> +       int i = 0;
> +
> +       memset(&obj, 0, sizeof(obj));
> +       memset(&execbuf, 0, sizeof(execbuf));
> +
> +       execbuf.buffers_ptr = to_user_pointer(&obj);
> +       execbuf.buffer_count = 1;
> +       execbuf.flags = engine;
> +       execbuf.flags |= I915_EXEC_SECURE;

That is asking to turn off the HW validator (for the most part), and
requires drm_open_driver_master(). But since you are doing something
illegal in a context that allows you to shoot yourself in the foot,
what's the point?  What does it prove?

> -       intel_batchbuffer_flush(batch);
> +       obj.handle = gem_create(fd, 4096);
> +
> +       batch[i++] = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;

Note that MI_STORE_DWORD doesn't even need a bad address to take over
the machine on some platforms. You should start with a validation that a
known good store works, before testing whether a bad one is skipped.
-Chris


More information about the Intel-gfx mailing list