From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Cc: akash.goel@intel.com
Subject: Re: [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation
Date: Thu, 3 Dec 2015 12:14:26 +0000 [thread overview]
Message-ID: <56603222.3020300@linux.intel.com> (raw)
In-Reply-To: <1449048293-4335-5-git-send-email-ankitprasad.r.sharma@intel.com>
Hi,
On 02/12/15 09:24, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> This patch verifies if the contents of the stolen backed object were
> preserved across hibernation. This is to validate kernel changes related
> to moving stolen-backed objects to shmem on hibernation.
>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Please Cc me if it is expected I keep reviewing this.
> ---
> tests/gem_stolen.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 86 insertions(+)
>
> diff --git a/tests/gem_stolen.c b/tests/gem_stolen.c
> index 3374716..1f13fb0 100644
> --- a/tests/gem_stolen.c
> +++ b/tests/gem_stolen.c
> @@ -290,6 +290,89 @@ static void stolen_fill_purge_test(int fd)
> gem_close(fd, handle[i]);
> }
>
> +static void stolen_hibernate(int fd)
> +{
> + drm_intel_bo *bo;
> + drm_intel_bo *src, *dest;
> + int obj_count = 0, i = 0;
> + int _ret = 0, j = 0;
Don't need to init _ret and j.
> + uint32_t handle[MAX_OBJECTS], src_handle;
> + uint32_t *virt;
> +
> + gem_require_stolen_support(fd);
> +
> + src_handle = gem_create(fd, SIZE);
> + igt_assert(!src_handle);
gem_create already asserts this, but isn't it also reversed? Does it run
and work?
> + src = gem_handle_to_libdrm_bo(bufmgr, fd,
> + "bo", src_handle);
> + igt_assert(src != NULL);
> +
> + _ret = drm_intel_gem_bo_map_gtt(src);
> + igt_assert(!_ret);
I think igt_assert_eq(ret, 0) is a preferred way nowadays.
Also a question, what is the special significance of _ret vs just normal
ret in this test?
> +
> + virt = src->virtual;
> + for (j = 0; j < SIZE/DWORD_SIZE; j++)
> + virt[j] = DATA;
memset?
> +
> + drm_intel_bo_unmap(src);
> + /* Exhaust Stolen space */
> + do {
> + handle[i] = __gem_create_stolen(fd, SIZE);
> + if (handle[i] != 0) {
Maybe it would be more readable and with less indentation:
for (i = 0; i < MAX_OBJECTS; i++) {
handle[i] = __gem_create_stolen(...);
if (!handle[i])
break;
...
obj_count++;
}
> + bo = gem_handle_to_libdrm_bo(bufmgr, fd,
> + "verify_bo", handle[i]);
> + igt_assert(bo != NULL);
> + _ret = drm_intel_gem_bo_map_gtt(bo);
> + igt_assert(!_ret);
> +
> + virt = bo->virtual;
> + for (j = 0; j < SIZE/DWORD_SIZE; j++)
> + igt_assert(!virt[j]);
Again, people will probably want igt_assert_eq.
> +
> + drm_intel_bo_unmap(bo);
> + drm_intel_bo_unreference(bo);
> +
> + obj_count++;
> + }
> +
> + i++;
> + } while (handle[i-1] && i < MAX_OBJECTS);
> +
> + igt_assert(obj_count > 0);
> +
> + for (i = 0; i < obj_count; i++) {
> + dest = gem_handle_to_libdrm_bo(bufmgr, fd,
> + "dst_bo", handle[i]);
> + igt_assert(dest != NULL);
> + intel_copy_bo(batch, dest, src, SIZE);
> + drm_intel_bo_unreference(dest);
> + }
Probably worth doing a verification step after each blit. So after
resume is not the first time you are checking it.
> + drm_intel_bo_unreference(src);
> +
> + igt_system_hibernate_autoresume();
> + /* Check if the object's memory contents are intact
> + * across hibernation.
> + */
> + for (i = 0; i < obj_count; i++) {
> + bo = gem_handle_to_libdrm_bo(bufmgr, fd,
> + "verify_bo", handle[i]);
> + igt_assert(bo != NULL);
> + _ret = drm_intel_gem_bo_map_gtt(bo);
> + igt_assert(!_ret);
> + virt = bo->virtual;
> + for (j = 0; j < SIZE/DWORD_SIZE; j++)
> + igt_assert_eq(virt[j], DATA);
> +
> + drm_intel_bo_unmap(bo);
> + drm_intel_bo_unreference(bo);
> + }
Would it be interesting to fill the bos with some more elaborate pattern
to potentially catch more potential corruption types?
Perhaps incrementing dwords would simply do?
> + gem_close(fd, src_handle);
> + for (i = 0; i < obj_count; i++)
> + gem_close(fd, handle[i]);
> +}
> +
> static void
> stolen_no_mmap(int fd)
> {
> @@ -353,6 +436,9 @@ igt_main
> igt_subtest("stolen-fill-purge")
> stolen_fill_purge_test(fd);
>
> + igt_subtest("stolen-hibernate")
> + stolen_hibernate(fd);
> +
> igt_fixture {
> intel_batchbuffer_free(batch);
> drm_intel_bufmgr_destroy(bufmgr);
>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-12-03 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-02 9:24 [PATCH v4 0/3] Tests for verifying the old and extended GEM_CREATE ioctl ankitprasad.r.sharma
2015-12-02 9:24 ` [PATCH 1/4] igt/gem_stolen: Verifying extended gem_create ioctl ankitprasad.r.sharma
2015-12-02 9:24 ` [PATCH 2/4] igt/gem_pread: Support to verify pread/pwrite for non-shmem backed obj ankitprasad.r.sharma
2015-12-02 9:24 ` [PATCH 3/4] igt/gem_create: Test to validate parameters for GEM_CREATE ioctl ankitprasad.r.sharma
2015-12-02 9:24 ` [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation ankitprasad.r.sharma
2015-12-03 12:14 ` Tvrtko Ursulin [this message]
2015-12-04 10:04 ` Tvrtko Ursulin
-- strict thread matches above, loose matches on Subject: below --
2015-12-22 10:07 [PATCH v6 0/4] Tests for verifying the old and extended GEM_CREATE ioctl ankitprasad.r.sharma
2015-12-22 10:07 ` [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation ankitprasad.r.sharma
2015-12-22 16:00 ` Tvrtko Ursulin
2015-12-22 16:17 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56603222.3020300@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=akash.goel@intel.com \
--cc=ankitprasad.r.sharma@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.