Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Alan Previn <alan.previn.teres.alexis@intel.com>
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t v15 01/15] i915_drm.h sync
Date: Wed, 6 Oct 2021 04:57:27 -0400	[thread overview]
Message-ID: <YV1k96r3Frmafwfi@intel.com> (raw)
In-Reply-To: <20211005194133.13508-2-alan.previn.teres.alexis@intel.com>

On Tue, Oct 05, 2021 at 12:41:19PM -0700, Alan Previn wrote:
> Sync UAPI changes to get I915_PROTECTED_CONTENT_DEFAULT_SESSION value
> as well as GEM_CREATE_EXT's I915_OBJECT_PARAM_PROTECTED_CONTENT
> and GEM_CONTEXT_CREATE's I915_CONTEXT_PARAM_PROTECTED_CONTENT.
> 
> Taken from kernel commit:
> commit d3ac8d42168a9be7380be8035df8b6d3780ec2a1
>        ("drm/i915/pxp: interfaces for using protected objects")
> 
> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com>

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

> ---
>  include/drm-uapi/i915_drm.h | 147 +++++++++++++++++++++++++++++++++++-
>  1 file changed, 146 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
> index b9632bb2..50c9308b 100644
> --- a/include/drm-uapi/i915_drm.h
> +++ b/include/drm-uapi/i915_drm.h
> @@ -572,6 +572,15 @@ typedef struct drm_i915_irq_wait {
>  #define   I915_SCHEDULER_CAP_PREEMPTION	(1ul << 2)
>  #define   I915_SCHEDULER_CAP_SEMAPHORES	(1ul << 3)
>  #define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS	(1ul << 4)
> +/*
> + * Indicates the 2k user priority levels are statically mapped into 3 buckets as
> + * follows:
> + *
> + * -1k to -1	Low priority
> + * 0		Normal priority
> + * 1 to 1k	Highest priority
> + */
> +#define   I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP	(1ul << 5)
>  
>  #define I915_PARAM_HUC_STATUS		 42
>  
> @@ -674,6 +683,9 @@ typedef struct drm_i915_irq_wait {
>   */
>  #define I915_PARAM_HAS_EXEC_TIMELINE_FENCES 55
>  
> +/* Query if the kernel supports the I915_USERPTR_PROBE flag. */
> +#define I915_PARAM_HAS_USERPTR_PROBE 56
> +
>  /* Must be kept compact -- no holes and well documented */
>  
>  typedef struct drm_i915_getparam {
> @@ -923,6 +935,25 @@ struct drm_i915_gem_mmap_offset {
>   *	- I915_GEM_DOMAIN_GTT: Mappable aperture domain
>   *
>   * All other domains are rejected.
> + *
> + * Note that for discrete, starting from DG1, this is no longer supported, and
> + * is instead rejected. On such platforms the CPU domain is effectively static,
> + * where we also only support a single &drm_i915_gem_mmap_offset cache mode,
> + * which can't be set explicitly and instead depends on the object placements,
> + * as per the below.
> + *
> + * Implicit caching rules, starting from DG1:
> + *
> + *	- If any of the object placements (see &drm_i915_gem_create_ext_memory_regions)
> + *	  contain I915_MEMORY_CLASS_DEVICE then the object will be allocated and
> + *	  mapped as write-combined only.
> + *
> + *	- Everything else is always allocated and mapped as write-back, with the
> + *	  guarantee that everything is also coherent with the GPU.
> + *
> + * Note that this is likely to change in the future again, where we might need
> + * more flexibility on future devices, so making this all explicit as part of a
> + * new &drm_i915_gem_create_ext extension is probable.
>   */
>  struct drm_i915_gem_set_domain {
>  	/** @handle: Handle for the object. */
> @@ -1815,6 +1846,55 @@ struct drm_i915_gem_context_param {
>   * attempted to use it, never re-use this context param number.
>   */
>  #define I915_CONTEXT_PARAM_RINGSIZE	0xc
> +
> +/*
> + * I915_CONTEXT_PARAM_PROTECTED_CONTENT:
> + *
> + * Mark that the context makes use of protected content, which will result
> + * in the context being invalidated when the protected content session is.
> + * Given that the protected content session is killed on suspend, the device
> + * is kept awake for the lifetime of a protected context, so the user should
> + * make sure to dispose of them once done.
> + * This flag can only be set at context creation time and, when set to true,
> + * must be preceded by an explicit setting of I915_CONTEXT_PARAM_RECOVERABLE
> + * to false. This flag can't be set to true in conjunction with setting the
> + * I915_CONTEXT_PARAM_BANNABLE flag to false. Creation example:
> + *
> + * .. code-block:: C
> + *
> + *	struct drm_i915_gem_context_create_ext_setparam p_protected = {
> + *		.base = {
> + *			.name = I915_CONTEXT_CREATE_EXT_SETPARAM,
> + *		},
> + *		.param = {
> + *			.param = I915_CONTEXT_PARAM_PROTECTED_CONTENT,
> + *			.value = 1,
> + *		}
> + *	};
> + *	struct drm_i915_gem_context_create_ext_setparam p_norecover = {
> + *		.base = {
> + *			.name = I915_CONTEXT_CREATE_EXT_SETPARAM,
> + *			.next_extension = to_user_pointer(&p_protected),
> + *		},
> + *		.param = {
> + *			.param = I915_CONTEXT_PARAM_RECOVERABLE,
> + *			.value = 0,
> + *		}
> + *	};
> + *	struct drm_i915_gem_context_create_ext create = {
> + *		.flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
> + *		.extensions = to_user_pointer(&p_norecover);
> + *	};
> + *
> + *	ctx_id = gem_context_create_ext(drm_fd, &create);
> + *
> + * In addition to the normal failure cases, setting this flag during context
> + * creation can result in the following errors:
> + *
> + * -ENODEV: feature not available
> + * -EPERM: trying to mark a recoverable or not bannable context as protected
> + */
> +#define I915_CONTEXT_PARAM_PROTECTED_CONTENT    0xd
>  /* Must be kept compact -- no holes and well documented */
>  
>  	__u64 value;
> @@ -2203,12 +2283,29 @@ struct drm_i915_gem_userptr {
>  	 * through the GTT. If the HW can't support readonly access, an error is
>  	 * returned.
>  	 *
> +	 * I915_USERPTR_PROBE:
> +	 *
> +	 * Probe the provided @user_ptr range and validate that the @user_ptr is
> +	 * indeed pointing to normal memory and that the range is also valid.
> +	 * For example if some garbage address is given to the kernel, then this
> +	 * should complain.
> +	 *
> +	 * Returns -EFAULT if the probe failed.
> +	 *
> +	 * Note that this doesn't populate the backing pages, and also doesn't
> +	 * guarantee that the object will remain valid when the object is
> +	 * eventually used.
> +	 *
> +	 * The kernel supports this feature if I915_PARAM_HAS_USERPTR_PROBE
> +	 * returns a non-zero value.
> +	 *
>  	 * I915_USERPTR_UNSYNCHRONIZED:
>  	 *
>  	 * NOT USED. Setting this flag will result in an error.
>  	 */
>  	__u32 flags;
>  #define I915_USERPTR_READ_ONLY 0x1
> +#define I915_USERPTR_PROBE 0x2
>  #define I915_USERPTR_UNSYNCHRONIZED 0x80000000
>  	/**
>  	 * @handle: Returned handle for the object.
> @@ -2360,7 +2457,7 @@ struct drm_i915_perf_open_param {
>   * Change metrics_set captured by a stream.
>   *
>   * If the stream is bound to a specific context, the configuration change
> - * will performed __inline__ with that context such that it takes effect before
> + * will performed inline with that context such that it takes effect before
>   * the next execbuf submission.
>   *
>   * Returns the previously bound metrics set id, or a negative error code.
> @@ -2931,8 +3028,12 @@ struct drm_i915_gem_create_ext {
>  	 *
>  	 * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see
>  	 * struct drm_i915_gem_create_ext_memory_regions.
> +	 *
> +	 * For I915_GEM_CREATE_EXT_PROTECTED_CONTENT usage see
> +	 * struct drm_i915_gem_create_ext_protected_content.
>  	 */
>  #define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0
> +#define I915_GEM_CREATE_EXT_PROTECTED_CONTENT 1
>  	__u64 extensions;
>  };
>  
> @@ -2990,6 +3091,50 @@ struct drm_i915_gem_create_ext_memory_regions {
>  	__u64 regions;
>  };
>  
> +/**
> + * struct drm_i915_gem_create_ext_protected_content - The
> + * I915_OBJECT_PARAM_PROTECTED_CONTENT extension.
> + *
> + * If this extension is provided, buffer contents are expected to be protected
> + * by PXP encryption and require decryption for scan out and processing. This
> + * is only possible on platforms that have PXP enabled, on all other scenarios
> + * using this extension will cause the ioctl to fail and return -ENODEV. The
> + * flags parameter is reserved for future expansion and must currently be set
> + * to zero.
> + *
> + * The buffer contents are considered invalid after a PXP session teardown.
> + *
> + * The encryption is guaranteed to be processed correctly only if the object
> + * is submitted with a context created using the
> + * I915_CONTEXT_PARAM_PROTECTED_CONTENT flag. This will also enable extra checks
> + * at submission time on the validity of the objects involved.
> + *
> + * Below is an example on how to create a protected object:
> + *
> + * .. code-block:: C
> + *
> + *      struct drm_i915_gem_create_ext_protected_content protected_ext = {
> + *              .base = { .name = I915_GEM_CREATE_EXT_PROTECTED_CONTENT },
> + *              .flags = 0,
> + *      };
> + *      struct drm_i915_gem_create_ext create_ext = {
> + *              .size = PAGE_SIZE,
> + *              .extensions = (uintptr_t)&protected_ext,
> + *      };
> + *
> + *      int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext);
> + *      if (err) ...
> + */
> +struct drm_i915_gem_create_ext_protected_content {
> +	/** @base: Extension link. See struct i915_user_extension. */
> +	struct i915_user_extension base;
> +	/** @flags: reserved for future usage, currently MBZ */
> +	__u32 flags;
> +};
> +
> +/* ID of the protected content session managed by i915 when PXP is active */
> +#define I915_PROTECTED_CONTENT_DEFAULT_SESSION 0xf
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> -- 
> 2.25.1
> 

  reply	other threads:[~2021-10-06  8:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 19:41 [PATCH i-g-t v15 00/15] Introduce PXP Test Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 01/15] i915_drm.h sync Alan Previn
2021-10-06  8:57   ` Rodrigo Vivi [this message]
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 02/15] Add basic PXP testing of buffer and context alloc Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 03/15] Perform a regular 3d copy as a control checkpoint Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 04/15] Add PXP attribute support in batchbuffer and buffer_ops libs Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 05/15] Add MI_SET_APPID instruction definition Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 06/15] Enable protected session cmd in gen12_render_copyfunc Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 07/15] Add subtest to copy raw source to protected dest Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 08/15] Add test where both src and dest are protected Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 09/15] Verify PXP teardown occurred through suspend-resume Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 10/15] Verify execbuf fails with stale PXP context after teardown Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 11/15] Verify execbuf fails with stale PXP buffer " Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 12/15] Verify execbuf ok with stale PXP buf in opt-out use Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 13/15] Verify execution behavior with stale PXP assets through suspend-resume Alan Previn
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 14/15] Verify protected surfaces are dma buffer sharable Alan Previn
2021-10-06 14:31   ` Ruhl, Michael J
2021-10-06 16:00     ` Teres Alexis, Alan Previn
2021-10-06 16:18       ` Vivi, Rodrigo
2021-10-06 17:07       ` Ruhl, Michael J
2021-10-05 19:41 ` [igt-dev] [PATCH i-g-t v15 15/15] tests/i915_pxp: CRC validation for display tests Alan Previn
2021-10-05 22:12 ` [igt-dev] ✓ Fi.CI.BAT: success for Introduce PXP Test (rev15) Patchwork
2021-10-06  3:02 ` [igt-dev] ✗ Fi.CI.IGT: failure " 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=YV1k96r3Frmafwfi@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=alan.previn.teres.alexis@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox