All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
	"Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
Subject: Re: [PATCH i-g-t v3 6/7] tests/intel/xe_pxp: Termination tests
Date: Thu, 13 Feb 2025 23:30:58 +0000	[thread overview]
Message-ID: <4705946cc555615049c5af22fcdfe28c38d8f773.camel@intel.com> (raw)
In-Reply-To: <20250213003904.2059770-7-daniele.ceraolospurio@intel.com>

Thanks for the tweaks / refactors from last review - all looks good now:

Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com>


On Wed, 2025-02-12 at 16:39 -0800, Ceraolo Spurio, Daniele wrote:
> There are several events that can cause the PXP key to be invalidated
> and trigger a PXP termination (suspend, PXP termination irq). After a
> termination, we expect the key to be different and the raw encrypted
> data to change for the same source data.
> Additionally, all PXP objects are invalidated during a termination and
> can no longer be used in submission or kept mapped to VMs; we therefore
> need to test both the execution and bind ioctls to make sure they work
> as expected after a termination.
> 
> v2: move igt_require calls inside the subtest
> v3: block rpm for tests trying a different type of termination, rework
> invalid bind test to try a new vm as well (Alan)
> 
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Alan Previn <alan.previn.teres.alexis@intel.com>
> 
alan:snip

> +static void pxp_vm_bind_sync(int fd, uint32_t vm, uint32_t bo, uint64_t addr,
> +                            uint64_t size, uint32_t op)
> +{
> +       struct drm_xe_sync sync = {
> +               .type = DRM_XE_SYNC_TYPE_SYNCOBJ,
> +               .flags = DRM_XE_SYNC_FLAG_SIGNAL,
> +               .handle = syncobj_create(fd, 0),
> +       };
> +
> +       __xe_vm_bind_assert(fd, vm, 0, bo, 0, addr, size, op,
> +                           DRM_XE_VM_BIND_FLAG_CHECK_PXP, &sync, 1, 0, 0);
> +
> +       igt_assert(syncobj_wait(fd, &sync.handle, 1, INT64_MAX, 0, NULL));
> +       syncobj_destroy(fd, sync.handle);
> +}
> +
> +/**
> + * SUBTEST: pxp-stale-bo-bind-post-termination-irq
> + * Description: verify that VM bind on a stale BO (due to a termination irq) is rejected.
> + */
> +
> +/**
> + * SUBTEST: pxp-stale-bo-bind-post-suspend
> + * Description: verify that VM bind on a stale BO (due to a suspend/resume cycle)
> + *              is rejected.
> + */
> +
> +/**
> + * SUBTEST: pxp-stale-bo-bind-post-rpm
> + * Description: verify that VM bind on a stale BO (due to a runtime suspend/resume
> + *              cycle) is rejected.
> + */
> +
> +static void __test_pxp_stale_bo_bind(int fd, enum termination_type type, bool pxp)
> +{
> +       uint32_t vm, q;
> +       uint32_t bo;
> +       uint32_t flags = pxp ? DRM_XE_VM_BIND_FLAG_CHECK_PXP : 0;
> +       int ret;
> +
> +       vm = xe_vm_create(fd, 0, 0);
> +       q = create_pxp_rcs_queue(fd, vm); /* start PXP session */
> +
> +       bo = pxp_bo_create(fd, 0, 4096, DRM_XE_PXP_TYPE_HWDRM);
> +
> +       /* map the BO to the VM to make sure it works */
> +       pxp_vm_bind_sync(fd, vm, bo, 0, 4096, DRM_XE_VM_BIND_OP_MAP);
> +
> +       xe_exec_queue_destroy(fd, q);
> +       trigger_termination(fd, type);
> +
> +       /* map of a stale PXP BO must fail if (and only if) the CHECK_PXP flag is set */
> +       ret = __xe_vm_bind(fd, vm, 0, bo, 0, 0, 4096, DRM_XE_VM_BIND_OP_MAP,
> +                          flags, NULL, 0, 0, DEFAULT_PAT_INDEX, 0);
> +       igt_assert_eq(ret, pxp ? -ENOEXEC : 0);
> +
> +       /* unmap must always work */
> +       pxp_vm_bind_sync(fd, vm, bo, 0, 0, DRM_XE_VM_BIND_OP_UNMAP_ALL);
> +
> +       xe_vm_destroy(fd, vm);
> 
alan: The rework in this function means we are more targetted on
addressing the different aspects of the expected UAPI behaviors.
Nice! - thanks.
> +
> +       /* mapping on a brand new vm should have the same behavior */
> +       vm = xe_vm_create(fd, 0, 0);
> +       ret = __xe_vm_bind(fd, vm, 0, bo, 0, 0, 4096, DRM_XE_VM_BIND_OP_MAP,
> +                          flags, NULL, 0, 0, DEFAULT_PAT_INDEX, 0);
> +       igt_assert_eq(ret, pxp ? -ENOEXEC : 0);
> +
> +       gem_close(fd, bo);
> +       xe_vm_destroy(fd, vm);
> +}
> +
> 
alan:snip
>  
> +static void termination_tests(int fd, bool pxp_supported, uint32_t devid,
> +                             enum termination_type type, const char *tag)
> +{
> +       int fw_handle;
> +
> +       if (type != PXP_TERMINATION_RPM) {
> +               /* avoid rpm entry for non-rpm tests */
> +               fw_handle = igt_debugfs_open(fd, "forcewake_all", O_RDONLY);
> +               igt_require(fw_handle >= 0);
> +       } else {
> +               igt_setup_runtime_pm(fd);
> +       }
alan: This is a better approach here - now we can guarantee control
over it being a runtime-rpm triggered teardown vs other trigger types.
Thanks for this change.
> +
> +       igt_subtest_f("pxp-termination-key-update-post-%s", tag) {
> +               require_pxp_render(pxp_supported, devid);
> +               test_pxp_teardown_keychange(fd, type);
> +       }
> +       igt_subtest_f("pxp-stale-bo-bind-post-%s", tag) {
> +               require_pxp(pxp_supported);
> +               test_pxp_stale_bo_bind(fd, type);
> +       }
> +       igt_subtest_f("pxp-stale-bo-exec-post-%s", tag) {
> +               require_pxp(pxp_supported);
> +               test_pxp_stale_bo_exec(fd, type);
> +       }
> +
> +       /* An active PXP queue holds an RPM ref, so we can't test RPM with it */
> +       if (type != PXP_TERMINATION_RPM) {
> +               igt_subtest_f("pxp-stale-queue-post-%s", tag) {
> +                       require_pxp(pxp_supported);
> +                       test_pxp_stale_queue_execution(fd, type);
> +               }
> +
> +               close(fw_handle);
> +       } else {
> +               igt_restore_runtime_pm();
> +       }
> +}
> +
alan:snip

  reply	other threads:[~2025-02-13 23:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13  0:38 [PATCH i-g-t v3 0/7] Xe: Add tests for PXP Daniele Ceraolo Spurio
2025-02-13  0:38 ` [PATCH i-g-t v3 1/7] drm-uapi/xe: Sync with PXP uapi updates Daniele Ceraolo Spurio
2025-02-13 22:38   ` Teres Alexis, Alan Previn
2025-02-13  0:38 ` [PATCH i-g-t v3 2/7] tests/intel/xe_vm: Update invalid flag subtest with valid PXP flag Daniele Ceraolo Spurio
2025-02-13  0:38 ` [PATCH i-g-t v3 3/7] tests/intel/xe_query: Add test for PXP status query Daniele Ceraolo Spurio
2025-02-13  0:38 ` [PATCH i-g-t v3 4/7] tests/intel/xe_pxp: Add PXP object and queue creation tests Daniele Ceraolo Spurio
2025-02-13  0:38 ` [PATCH i-g-t v3 5/7] tests/intel/xe_pxp: Test PXP submissions Daniele Ceraolo Spurio
2025-02-13 22:47   ` Teres Alexis, Alan Previn
2025-02-13  0:39 ` [PATCH i-g-t v3 6/7] tests/intel/xe_pxp: Termination tests Daniele Ceraolo Spurio
2025-02-13 23:30   ` Teres Alexis, Alan Previn [this message]
2025-02-14 20:07   ` Kamil Konieczny
2025-02-21  0:44     ` Daniele Ceraolo Spurio
2025-02-13  0:39 ` [PATCH i-g-t v3 7/7] tests/intel/xe_pxp: Test encrypted FBs Daniele Ceraolo Spurio
2025-02-13  2:58 ` ✗ GitLab.Pipeline: warning for Xe: Add tests for PXP (rev3) Patchwork

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=4705946cc555615049c5af22fcdfe28c38d8f773.camel@intel.com \
    --to=alan.previn.teres.alexis@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=igt-dev@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.