Re: [Intel-gfx] [PATCH v6 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

2023-03-02 Thread Teres Alexis, Alan Previn 
On Mon, 2023-02-27 at 18:21 -0800, Teres Alexis, Alan Previn wrote:
> Add helper functions into a new file for heci-packet-submission.
> The helpers will handle generating the MTL GSC-CS Memory-Header
> and submission of the Heci-Cmd-Packet instructions to the engine.
> 
> 
alan:snip

> +int
> +intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
> +  struct intel_context *ce,
> +  struct intel_gsc_heci_non_priv_pkt *pkt,
> +  u32 *cmd, int timeout_ms)
> +{
> + struct intel_engine_cs *eng;
> + struct i915_request *rq;
> + int err;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + emit_gsc_heci_pkt_nonpriv(cmd, pkt);
> +
> + i915_vma_lock(pkt->bb_vma);
> + err = i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
> + i915_vma_unlock(pkt->bb_vma);
> + if (err)
> + goto out_rq;
> +

alan:
depending on timing (appears to be a racy trigger event), in <5% of the time 
when I tested this internally,
I am seeing lockdep issues when running live_selftests(gt_timelines)  followed 
by a PXP teardown at pxp-fini.
The lockdep kernel logs point to the sequence of calling 
"intel_context_create_request" followed by
i915_vma_lock/move_to_active/i915_vma_unlock for the objects (and how the 
internal ww-locks vs timeline-locks are taken)

Internal discussions realize that i really shouldnt be using these function 
call sequences and should instead
follow what our workaround batch buffers do:

(the following is the current fix proposal from internal discussions, but i 
still need to do more testing +
debug before i re-rev but i wanted to put this review comment first so the 
follow-up action is not lost)

i915_gem_ww_ctx_init(, false);
i915_gem_object_lock(pkt->bb_vma->obj, );
intel_context_pin_ww(ce, );
i915_request_create(ce);
i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);

submit (breadcrumbs, init-bb, flush...)

i915_request_get/add/put(rq);
intel_context_unpin(ce);
i915_gem_ww_ctx_fini();

alan:snip

[Intel-gfx] [PATCH v6 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

2023-02-27 Thread Alan Previn 
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.

NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
 1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
 2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
 3- PXP: This series.

NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.

NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
   common helpers come in:
 - On MTL, when an i915 subsystem needs to send a command request
   to the security firmware, it will send that via the GSC-
   engine-command-streamer.
 - However those commands, (lets call them "gsc_specific_fw_api"
   calls), are not understood by the GSC command streamer hw.
 - The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
   passes it along to the GSC firmware.
 - The GSC FW on the other hand needs additional metadata to know
   which usage service is being called (PXP, HDCP, proxy, etc) along
   with session specific info. Thus an extra header called GSC-CS
   HECI Memory Header, (C) in below diagram is prepended before
   the FW specific API, (D).
 - Thus, the structural layout of the request submitted would
   need to look like the diagram below (for non-priv PXP).
 - In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
   PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
   will populate blob (C) while additional helpers, different for
   PPGGTT (this patch) vs GGTT (HDCP series) will populate
   blobs (A) and (B) below.
  ___
 (A)  |  MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
  | |   |
  |_|   |
  | (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,|   |
  ||   pkt-addr-out, pkt-size-out)  |
  || MI_BATCH_BUFFER_END|   |   |
  |||   |   |
  | |   |
  |_|   |
|
-
|
   \|/
  __V___
  |   _|
  |(C)|   ||
  |   | struct intel_gsc_mtl_header { ||
  |   |   validity marker ||
  |   |   heci_clent_id   ||
  |   |   ... ||
  |   |  }||
  |   |___||
  |(D)|   ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   | ...   ||
  |   | For an example, see   ||
  |   | 'struct pxp43_create_arb_in' at   ||
  |   | intel_pxp_cmd_interface_43.h  ||
  |   |   ||
  |   | } ||
  |   |  Struture depends on command type ||
  |   | struct gsc_fw_specific_api_foobar {   ||
  |   |___||
  ||

That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |   2 +
 .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 108