Re: [Intel-gfx] [RFC 0/7] drm/i915/pxp: Create a backend abstraction layer for pxp-tee-link

2022-12-02 Thread Teres Alexis, Alan Previn
++Rodrigo, Daniele, Jani.

Hey folks - any concerns with this approach? 

i915->pxp--->[feature functions]
|---> [tee-backends-folder]
|--->mei-pxp transport functions (legacy)
|--->gsccs transport functions (mtl+)

tee backend folder basically abstracts away the transport mechanism to get PXP 
messages
to and from PXP firmware service. the goal is to keep the upper layer of PXP 
somewhat
agnostic to the bottom later and let the bottom later handle backend assets and 
flows
depending on the platform. 

Today the mei-pxp functions called directly by the pxp main functions and in 
future to
avoid a whole bunch of "if (genx) else (gen-mtl) i want to create a set of 
function ptrs
the backend will populate at init (and also a backend-private context) so that 
the
abstraction can be clean and modular:

struct intel_pxp {
...
struct {
/** @priv: Pointer exclusively for backend layer to store 
private context.*/
void *priv;
/** @init: Func-ptr called to initialize the backend transport 
resources.*/
int (*init)(struct intel_pxp *pxp);
/** @fini: Func-ptr called to free the backend transport 
resources.*/
void (*fini)(struct intel_pxp *pxp);
/**
 * @is_ready: Func-ptr called to query if the backend transport 
is available
 * for use. Depending on the backend, some, such as mei, have 
asyncronous workers
 * or callbacks that setup the backend tee link to the security 
firmware.
 **/
bool (*is_ready)(struct intel_pxp *pxp);
/** @init: Func-ptr called to create a pxp session.*/
int (*create_session)(struct intel_pxp *pxp, int session_id);
/** @init: Func-ptr called to send message packets to pxp 
firmware.*/
int (*send_message)(struct intel_pxp *pxp,
void *msg_in, size_t msg_in_len,
void *msg_out, size_t msg_out_max_len,
} tee_link;
};

...alan

On Wed, 2022-11-23 at 14:34 -0800, Alan Previn wrote:
> PXP is a feature allowing workloads executing on engines to operate with
> encrypted buffers (via specific state instructions). On the other hand, PXP 
> controls
> for operations like arbitration session creation and global teardown of PXP 
> sessions
> require communicating with the security firmware.
> 
> The transport layer to establish, execute and shutdown communication with the 
> security
> firmware is different between TGL/ADL vs MTL. The former uses the mei 
> component driver
> interfaces while the latter depends on the media-tile's GSC-command-streamer. 
> Both cases
> have very different code flow and assets.
> 
> This series aims to create a clean partition between the front end of the PXP 
> subsystem
> and the backend-tee transport layer. The goal here is to present an intuitive 
> layering
> using backend function pointers that will scale for future hardware backends
> while keeping the front end agnostic to the backend details.
> 
> 
> Alan Previn (7):
>   HAX: drm/i915/pxp: Prepare intel_pxp entry points for MTL
>   drm/i915/pxp: Refactor mei-teelink checks at init/fini
>   drm/i915/pxp: Abstract mei-teelink function access via backend ptrs
>   drm/i915/pxp: Separate tee-link front end interfaces from backend
> implementation
>   drm/i915/pxp: move mei-pxp and mei-gsc resources to be backend-private
>   drm/i915/pxp: Add PXP gsccs tee-link backend stubs
>   drm/i915/pxp: Better hierarchy readibility - move backends to a
> backend folder
> 
>  drivers/gpu/drm/i915/Makefile |   4 +-
>  .../drm/i915/display/skl_universal_plane.c|   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_context.c   |   6 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c|   2 +-
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   2 +-
>  drivers/gpu/drm/i915/i915_drv.h   |   4 -
>  drivers/gpu/drm/i915/pxp/intel_pxp.c  | 103 +++--
>  drivers/gpu/drm/i915/pxp/intel_pxp.h  |  16 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c  |   2 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c  |   8 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |  13 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  |   4 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_pm.c   |  11 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |   2 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 310 ++
>  drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |  22 +-
>  drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  52 ++-
>  .../i915/pxp/tee_backends/intel_pxp_gsccs.c   |  48 +++
>  .../i915/pxp/tee_backends/intel_pxp_gsccs.h   |  13 +
>  .../i915/pxp/tee_backends/intel_pxp_tee_mei.c | 398 ++
>  .../i915/pxp/tee_backends/intel_pxp_tee_mei.h |  13 +
>  21 files changed, 677 

[Intel-gfx] [RFC 0/7] drm/i915/pxp: Create a backend abstraction layer for pxp-tee-link

2022-11-23 Thread Alan Previn
PXP is a feature allowing workloads executing on engines to operate with
encrypted buffers (via specific state instructions). On the other hand, PXP 
controls
for operations like arbitration session creation and global teardown of PXP 
sessions
require communicating with the security firmware.

The transport layer to establish, execute and shutdown communication with the 
security
firmware is different between TGL/ADL vs MTL. The former uses the mei component 
driver
interfaces while the latter depends on the media-tile's GSC-command-streamer. 
Both cases
have very different code flow and assets.

This series aims to create a clean partition between the front end of the PXP 
subsystem
and the backend-tee transport layer. The goal here is to present an intuitive 
layering
using backend function pointers that will scale for future hardware backends
while keeping the front end agnostic to the backend details.


Alan Previn (7):
  HAX: drm/i915/pxp: Prepare intel_pxp entry points for MTL
  drm/i915/pxp: Refactor mei-teelink checks at init/fini
  drm/i915/pxp: Abstract mei-teelink function access via backend ptrs
  drm/i915/pxp: Separate tee-link front end interfaces from backend
implementation
  drm/i915/pxp: move mei-pxp and mei-gsc resources to be backend-private
  drm/i915/pxp: Add PXP gsccs tee-link backend stubs
  drm/i915/pxp: Better hierarchy readibility - move backends to a
backend folder

 drivers/gpu/drm/i915/Makefile |   4 +-
 .../drm/i915/display/skl_universal_plane.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_create.c|   2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 -
 drivers/gpu/drm/i915/pxp/intel_pxp.c  | 103 +++--
 drivers/gpu/drm/i915/pxp/intel_pxp.h  |  16 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c  |   2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c  |   8 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_huc.c  |  13 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  |   4 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c   |  11 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |   2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 310 ++
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h  |  22 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  52 ++-
 .../i915/pxp/tee_backends/intel_pxp_gsccs.c   |  48 +++
 .../i915/pxp/tee_backends/intel_pxp_gsccs.h   |  13 +
 .../i915/pxp/tee_backends/intel_pxp_tee_mei.c | 398 ++
 .../i915/pxp/tee_backends/intel_pxp_tee_mei.h |  13 +
 21 files changed, 677 insertions(+), 358 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/pxp/tee_backends/intel_pxp_gsccs.c
 create mode 100644 drivers/gpu/drm/i915/pxp/tee_backends/intel_pxp_gsccs.h
 create mode 100644 drivers/gpu/drm/i915/pxp/tee_backends/intel_pxp_tee_mei.c
 create mode 100644 drivers/gpu/drm/i915/pxp/tee_backends/intel_pxp_tee_mei.h


base-commit: c8b2ce6e20662ef30130e65f473b1ff5362765e3
-- 
2.34.1