On Mon, Aug 16, 2021 at 06:51:19AM -0700, Matthew Brost wrote:

A small race that could result in incorrect accounting of the number of outstanding G2H. Basically prior to this patch we did not increment the number of outstanding G2H if we encoutered a GT reset while sending a H2G. This was incorrect as the context state had already been updated to anticipate a G2H response thus the counter should be incremented.

Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer") Signed-off-by: Matthew Brost matthew.brost@intel.com Cc: stable@vger.kernel.org

---

drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 69faa39da178..b5d3972ae164 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -360,11 +360,13 @@ static int guc_submission_send_busy_loop(struct intel_guc *guc, { int err;

• err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
• if (!err && g2h_len_dw)

• if (g2h_len_dw) atomic_inc(&guc->outstanding_submission_g2h);

• err = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);

I'm majorly confused by the _busy_loop naming scheme, especially here. Like "why do we want to send a busy loop comand to guc, this doesn't make sense".

It seems like you're using _busy_loop as a suffix for "this is ok to be called in atomic context". The linux kernel bikeshed for this is generally _atomic() (or _in_atomic() or something like that). Would be good to rename to make this slightly less confusing. -Daniel

• if (err == -EBUSY && g2h_len_dw)

• atomic_dec(&guc->outstanding_submission_g2h);
  

• return err;

}

-- 2.32.0

On Tue, Aug 17, 2021 at 11:32:56AM +0200, Daniel Vetter wrote:

On Mon, Aug 16, 2021 at 06:51:22AM -0700, Matthew Brost wrote:

...

If the context is reset as a result of the request cancelation the context reset G2H is received after schedule disable done G2H which is likely the wrong order. The schedule disable done G2H release the waiting request cancelation code which resubmits the context. This races with the context reset G2H which also wants to resubmit the context but in this case it really should be a NOP as request cancelation code owns the resubmit. Use some clever tricks of checking the context state to seal this race until if / when the GuC firmware is fixed.

v2: (Checkpatch)

• Fix typos

Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost matthew.brost@intel.com Cc: stable@vger.kernel.org

---

.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 43 ++++++++++++++++--- 1 file changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 3cd2da6f5c03..c3b7bf7319dd 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -826,17 +826,35 @@ __unwind_incomplete_requests(struct intel_context *ce) static void __guc_reset_context(struct intel_context *ce, bool stalled) { struct i915_request *rq;

• unsigned long flags; u32 head;

• bool skip = false;

  intel_context_get(ce);

  /*

• * GuC will implicitly mark the context as non-schedulable
  

• * when it sends the reset notification. Make sure our state
  

• * reflects this change. The context will be marked enabled
  

• * on resubmission.
  

• * GuC will implicitly mark the context as non-schedulable when it sends
  

• * the reset notification. Make sure our state reflects this change. The
  

• * context will be marked enabled on resubmission.
  

• *
  

• * XXX: If the context is reset as a result of the request cancellation
  

• * this G2H is received after the schedule disable complete G2H which is
  

• * likely wrong as this creates a race between the request cancellation
  

• * code re-submitting the context and this G2H handler. This likely
  

• * should be fixed in the GuC but until if / when that gets fixed we
  

• * need to workaround this. Convert this function to a NOP if a pending
  

• * enable is in flight as this indicates that a request cancellation has
  

• * occurred.
  

  */

• clr_context_enabled(ce);

• spin_lock_irqsave(&ce->guc_state.lock, flags);

• if (likely(!context_pending_enable(ce))) {

• clr_context_enabled(ce);
  

• } else {

• skip = true;
  

• }

• spin_unlock_irqrestore(&ce->guc_state.lock, flags);

• if (unlikely(skip))

• goto out_put;
  
  

  rq = intel_context_find_active_request(ce); if (!rq) {

@@ -855,6 +873,7 @@ static void __guc_reset_context(struct intel_context *ce, bool stalled) out_replay: guc_reset_state(ce, head, stalled); __unwind_incomplete_requests(ce); +out_put: intel_context_put(ce); }

@@ -1599,6 +1618,13 @@ static void guc_context_cancel_request(struct intel_context *ce, guc_reset_state(ce, intel_ring_wrap(ce->ring, rq->head), true); }

• /*
  

•  * XXX: Racey if context is reset, see comment in
  

•  * __guc_reset_context().
  

•  */
  

• flush_work(&ce_to_guc(ce)->ct.requests.worker);
  

This looks racy, and I think that holds in general for all the flush_work you're adding: This only flushes the processing of the work, it doesn't stop any re-queueing (as far as I can tell at least), which means it doesn't do a hole lot.

Worse, your task is re-queue because it only processes one item at a time. That means flush_work only flushes the first invocation, but not even drains them all. So even if you do prevent requeueing somehow, this isn't what you want. Two solutions.

• flush_work_sync, which flushes until self-requeues are all done too

• Or more preferred, make you're worker a bit more standard for this stuff: a) under the spinlock, take the entire list, not just the first entry, with list_move or similar to a local list b) process that local list in a loop b) don't requeue youreself.

This seems better, not sure what it currently doesn't do that as I didn't write that code.

Also BTW, confirmed with the GuC team the order of the G2H is incorrect and will get fixed in an upcoming release, once that happens most of this patch can get dropped.

Matt

Cheers, Daniel

...

• guc_context_unblock(ce); }

} @@ -2719,7 +2745,12 @@ static void guc_handle_context_reset(struct intel_guc *guc, { trace_intel_context_reset(ce);

• if (likely(!intel_context_is_banned(ce))) {

• /*

• * XXX: Racey if request cancellation has occurred, see comment in
  

• * __guc_reset_context().
  

• */
  

• if (likely(!intel_context_is_banned(ce) &&

•    !context_blocked(ce))) {
  

  capture_error_state(guc, ce); guc_context_replay(ce); }

-- 2.32.0

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On Mon, Aug 16, 2021 at 06:51:23AM -0700, Matthew Brost wrote:

Progagating errors to dependent fences is wrong, don't do it. Selftest in following patch exposes this bug.

Please explain what "this bug" is, it's hard to read minds, especially at a distance in spacetime :-)

Fixes: 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children on unhold")

I think it would be better to outright revert this, instead of just disabling it like this.

Also please cite the dma_fence error propagation revert from Jason:

commit 93a2711cddd5760e2f0f901817d71c93183c3b87 Author: Jason Ekstrand jason@jlekstrand.net Date: Wed Jul 14 14:34:16 2021 -0500

Revert "drm/i915: Propagate errors on awaiting already signaled fences"

Maybe in full, if you need the justification.

Signed-off-by: Matthew Brost matthew.brost@intel.com Cc: stable@vger.kernel.org

Unless "this bug" is some real world impact thing I wouldn't put cc: stable on this. -Daniel

---

drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ---- 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index de5f9c86b9a4..cafb0608ffb4 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -2140,10 +2140,6 @@ static void __execlists_unhold(struct i915_request *rq) if (p->flags & I915_DEPENDENCY_WEAK) continue;

• 	/* Propagate any change in error status */
  

• 	if (rq->fence.error)
  

• 		i915_request_set_error_once(w, rq->fence.error);
  

• if (w->engine != rq->engine)
  	continue;
  
  

-- 2.32.0

On Tue, Aug 17, 2021 at 5:13 PM Matthew Brost matthew.brost@intel.com wrote:

On Tue, Aug 17, 2021 at 11:21:27AM +0200, Daniel Vetter wrote:

...

On Mon, Aug 16, 2021 at 06:51:23AM -0700, Matthew Brost wrote:

...

Progagating errors to dependent fences is wrong, don't do it. Selftest in following patch exposes this bug.

Please explain what "this bug" is, it's hard to read minds, especially at a distance in spacetime :-)

Not a very good explaination.

...

...

Fixes: 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children on unhold")

I think it would be better to outright revert this, instead of just disabling it like this.

I tried revert and git did some really odd things that I couldn't resolve, hence the new patch.

If there's any conflict git just gives you your current code, and what was there with the revert applied, with the block markers. Then it's your job to manually apply that change.

Occasionally (when there's been ridiculous amounts of code movement) it gets completely lost and puts these into very non-intuitive places. In that case just delete it, keep the current code, and check what change you're missing that needs to be manually reverted still. Also sometimes there's a follow-up patch that you should revert first, which makes the revert clean. In that case it's generally the right thing to revert the follow-up first, and then apply your revert. Often there's subtle functional dependencies hiding. -Daniel

...

Also please cite the dma_fence error propagation revert from Jason:

commit 93a2711cddd5760e2f0f901817d71c93183c3b87 Author: Jason Ekstrand jason@jlekstrand.net Date: Wed Jul 14 14:34:16 2021 -0500

Revert "drm/i915: Propagate errors on awaiting already signaled fences"

Maybe in full, if you need the justification.

Will site.

...

...

Signed-off-by: Matthew Brost matthew.brost@intel.com Cc: stable@vger.kernel.org

Unless "this bug" is some real world impact thing I wouldn't put cc: stable on this.

Got it.

Matt

...

-Daniel

...

---

drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 ---- 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index de5f9c86b9a4..cafb0608ffb4 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -2140,10 +2140,6 @@ static void __execlists_unhold(struct i915_request *rq) if (p->flags & I915_DEPENDENCY_WEAK) continue;

•               /* Propagate any change in error status */
  

•               if (rq->fence.error)
  

•                       i915_request_set_error_once(w, rq->fence.error);
  

•               if (w->engine != rq->engine)
                        continue;
  
  

-- 2.32.0

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On Tue, Aug 17, 2021 at 11:47:53AM +0200, Daniel Vetter wrote:

On Mon, Aug 16, 2021 at 06:51:25AM -0700, Matthew Brost wrote:

...

When unblocking a context, do not enable scheduling if the context is banned, guc_id invalid, or not registered.

Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost matthew.brost@intel.com Cc: stable@vger.kernel.org

---

drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +++ 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index c3b7bf7319dd..353899634fa8 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -1579,6 +1579,9 @@ static void guc_context_unblock(struct intel_context *ce) spin_lock_irqsave(&ce->guc_state.lock, flags);

if (unlikely(submission_disabled(guc) ||

•      intel_context_is_banned(ce) ||
  

•      context_guc_id_invalid(ce) ||
  

•      !lrc_desc_registered(guc, ce->guc_id) ||
  !intel_context_is_pinned(ce) ||
  context_pending_disable(ce) ||
  context_blocked(ce) > 1)) {
  

I think this entire if condition here is screaming that our intel_context state machinery for guc is way too complex, and on the wrong side of incomprehensible.

Also some of these check state outside of the context, and we don't seem to hold spinlocks for those, or anything else.

I general I have no idea which of these are defensive programming and cannot ever happen, and which actually can happen. There's for sure way too many races going on given that this is all context-local stuff.

Races here meaining that we seem to be dropping locks while the context is in an inconsistent state, which then means that every other code path touching contexts needs to check whether the context is in an inconsistent state.

This is a bit an example of protecting code, vs protecting datastructures. Protecting code is having state bits of intermediate/transitional state leak outside of the locked section (like context_blocked), so that every other piece of code must be aware about the transition and not screw things up for worse when they race.

This means your review and validation effort scales O(N^2) with the amount of code and features you have. Which doesn't work.

Datastructure or object oriented locking design goes different:

1. You figure out what the invariants of your datastructure are. That means what should hold after each state transition is finished. I have no idea what is the solution for all them here, but e.g. why is context_blocked even visible to other threads? Usual approach is a) take lock b) do whatever is necessary (we're talking about reset stuff here, so performance really doesn't matter) c) unlock. I know that i915-gem is full of these leaky counting things, but that's really not a good design.

2. Next up, for every piece of state you think how it's protected with a per-object lock. The fewer locks you have (but still per-objects so it's not becoming a mess for different reasons) the higher chances that you don't leak inconsistent state to other threads. This is a bit tricky when multipled objects are involved, or if you have to split your locks for a single object because some of it needs to be accessed from irq context (like a tasklet).

3. Document your rules in kerneldoc, so that when new code gets added you don't have to review everything for consistency against the rules. This way you get overall O(N) effort for validation and review, because all you have to do is check every function that changes state against the overall contract, and not everything against everything else.

If you have a pile of if checks every time you grab a lock, your locking design has too much state that leaks outside of the locked sections. -Daniel

On Tue, Aug 17, 2021 at 12:06:16PM +0200, Daniel Vetter wrote:

On Mon, Aug 16, 2021 at 06:51:31AM -0700, Matthew Brost wrote:

...

Error captures can now be done in a work queue processing G2H messages. These messages need to be completely done being processed in the reset path, to avoid races in the missing G2H cleanup, which create a dependency on memory allocations and dma fences (i915_requests). Requests depend on resets, thus now we have a circular dependency. To work around this, allocate the error capture in an atomic context.

Fixes: dc0dad365c5e ("Fix for error capture after full GPU reset with GuC") Fixes: 573ba126aef3 ("Capture error state on context reset") Signed-off-by: Matthew Brost matthew.brost@intel.com

---

drivers/gpu/drm/i915/i915_gpu_error.c | 37 +++++++++++++-------------- 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 0f08bcfbe964..453376aa6d9f 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -49,7 +49,6 @@ #include "i915_memcpy.h" #include "i915_scatterlist.h"

-#define ALLOW_FAIL (GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN) #define ATOMIC_MAYFAIL (GFP_ATOMIC | __GFP_NOWARN)

This one doesn't make much sense. GFP_ATOMIC essentially means we're high-priority and failure would be a pretty bad day. Meanwhile __GFP_NOWARN means we can totally cope with failure, pls don't holler.

GFP_NOWAIT | __GFP_NOWARN would the more consistent one here I think.

gfp.h for all the docs for this.

Separate patch ofc. This one is definitely the right direction, since GFP_KERNEL from the reset worker is not a good idea.

Lockdep is happy with GFP_NOWAIT so this works for me.

Matt

-Daniel

...

static void __sg_set_buf(struct scatterlist *sg, @@ -79,7 +78,7 @@ static bool __i915_error_grow(struct drm_i915_error_state_buf *e, size_t len) if (e->cur == e->end) { struct scatterlist *sgl;

• sgl = (typeof(sgl))__get_free_page(ALLOW_FAIL);
  

• sgl = (typeof(sgl))__get_free_page(ATOMIC_MAYFAIL);
  

  if (!sgl) { e->err = -ENOMEM; return false;

@@ -99,10 +98,10 @@ static bool __i915_error_grow(struct drm_i915_error_state_buf *e, size_t len) }

e->size = ALIGN(len + 1, SZ_64K);

• e->buf = kmalloc(e->size, ALLOW_FAIL);

• e->buf = kmalloc(e->size, ATOMIC_MAYFAIL); if (!e->buf) { e->size = PAGE_ALIGN(len + 1);

• e->buf = kmalloc(e->size, GFP_KERNEL);
  

• e->buf = kmalloc(e->size, ATOMIC_MAYFAIL);
  

  } if (!e->buf) { e->err = -ENOMEM;

@@ -243,12 +242,12 @@ static bool compress_init(struct i915_vma_compress *c) { struct z_stream_s *zstream = &c->zstream;

• if (pool_init(&c->pool, ALLOW_FAIL))

• if (pool_init(&c->pool, ATOMIC_MAYFAIL)) return false;

  zstream->workspace = kmalloc(zlib_deflate_workspacesize(MAX_WBITS, MAX_MEM_LEVEL),

• 	ALLOW_FAIL);
  

• 	ATOMIC_MAYFAIL);
  

  if (!zstream->workspace) { pool_fini(&c->pool); return false;

@@ -256,7 +255,7 @@ static bool compress_init(struct i915_vma_compress *c)

c->tmp = NULL; if (i915_has_memcpy_from_wc())

• c->tmp = pool_alloc(&c->pool, ALLOW_FAIL);
  

• c->tmp = pool_alloc(&c->pool, ATOMIC_MAYFAIL);
  
  

  return true;

} @@ -280,7 +279,7 @@ static void *compress_next_page(struct i915_vma_compress *c, if (dst->page_count >= dst->num_pages) return ERR_PTR(-ENOSPC);

• page = pool_alloc(&c->pool, ALLOW_FAIL);

• page = pool_alloc(&c->pool, ATOMIC_MAYFAIL); if (!page) return ERR_PTR(-ENOMEM);

@@ -376,7 +375,7 @@ struct i915_vma_compress {

static bool compress_init(struct i915_vma_compress *c) {

• return pool_init(&c->pool, ALLOW_FAIL) == 0;

• return pool_init(&c->pool, ATOMIC_MAYFAIL) == 0;

}

static bool compress_start(struct i915_vma_compress *c) @@ -391,7 +390,7 @@ static int compress_page(struct i915_vma_compress *c, { void *ptr;

• ptr = pool_alloc(&c->pool, ALLOW_FAIL);

• ptr = pool_alloc(&c->pool, ATOMIC_MAYFAIL); if (!ptr) return -ENOMEM;

@@ -997,7 +996,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,

num_pages = min_t(u64, vma->size, vma->obj->base.size) >> PAGE_SHIFT; num_pages = DIV_ROUND_UP(10 * num_pages, 8); /* worstcase zlib growth */

• dst = kmalloc(sizeof(*dst) + num_pages * sizeof(u32 *), ALLOW_FAIL);

• dst = kmalloc(sizeof(*dst) + num_pages * sizeof(u32 *), ATOMIC_MAYFAIL); if (!dst) return NULL;

@@ -1433,7 +1432,7 @@ capture_engine(struct intel_engine_cs *engine, struct i915_request *rq = NULL; unsigned long flags;

• ee = intel_engine_coredump_alloc(engine, GFP_KERNEL);

• ee = intel_engine_coredump_alloc(engine, ATOMIC_MAYFAIL); if (!ee) return NULL;

@@ -1481,7 +1480,7 @@ gt_record_engines(struct intel_gt_coredump *gt, struct intel_engine_coredump *ee;

/* Refill our page pool before entering atomic section */

• pool_refill(&compress->pool, ALLOW_FAIL);
  

• pool_refill(&compress->pool, ATOMIC_MAYFAIL);
  
  

  ee = capture_engine(engine, compress); if (!ee)

@@ -1507,7 +1506,7 @@ gt_record_uc(struct intel_gt_coredump *gt, const struct intel_uc *uc = &gt->_gt->uc; struct intel_uc_coredump *error_uc;

• error_uc = kzalloc(sizeof(*error_uc), ALLOW_FAIL);

• error_uc = kzalloc(sizeof(*error_uc), ATOMIC_MAYFAIL); if (!error_uc) return NULL;

@@ -1518,8 +1517,8 @@ gt_record_uc(struct intel_gt_coredump *gt, * As modparams are generally accesible from the userspace make * explicit copies of the firmware paths. */

• error_uc->guc_fw.path = kstrdup(uc->guc.fw.path, ALLOW_FAIL);
• error_uc->huc_fw.path = kstrdup(uc->huc.fw.path, ALLOW_FAIL);

• error_uc->guc_fw.path = kstrdup(uc->guc.fw.path, ATOMIC_MAYFAIL);
• error_uc->huc_fw.path = kstrdup(uc->huc.fw.path, ATOMIC_MAYFAIL); error_uc->guc_log = i915_vma_coredump_create(gt->_gt, uc->guc.log.vma, "GuC log buffer",

@@ -1778,7 +1777,7 @@ i915_vma_capture_prepare(struct intel_gt_coredump *gt) { struct i915_vma_compress *compress;

• compress = kmalloc(sizeof(*compress), ALLOW_FAIL);

• compress = kmalloc(sizeof(*compress), ATOMIC_MAYFAIL); if (!compress) return NULL;

@@ -1811,11 +1810,11 @@ i915_gpu_coredump(struct intel_gt *gt, intel_engine_mask_t engine_mask) if (IS_ERR(error)) return error;

• error = i915_gpu_coredump_alloc(i915, ALLOW_FAIL);

• error = i915_gpu_coredump_alloc(i915, ATOMIC_MAYFAIL); if (!error) return ERR_PTR(-ENOMEM);

• error->gt = intel_gt_coredump_alloc(gt, ALLOW_FAIL);

• error->gt = intel_gt_coredump_alloc(gt, ATOMIC_MAYFAIL); if (error->gt) { struct i915_vma_compress *compress;

-- 2.32.0

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On Mon, Aug 16, 2021 at 06:51:32AM -0700, Matthew Brost wrote:

It isn't safe to scrub for missing G2H or continue with the reset until all G2H processing is complete. Flush the G2H work queue during reset to ensure it is done running.

Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost matthew.brost@intel.com

---

.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 ++---------------- 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 3a01743e09ea..8c560ed14976 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -707,8 +707,6 @@ static void guc_flush_submissions(struct intel_guc *guc)

void intel_guc_submission_reset_prepare(struct intel_guc *guc) {

• int i;
• if (unlikely(!guc_submission_initialized(guc))) { /* Reset called during driver load? GuC not yet initialised! */ return;

@@ -724,20 +722,8 @@ void intel_guc_submission_reset_prepare(struct intel_guc *guc)

guc_flush_submissions(guc);

• /*

• * Handle any outstanding G2Hs before reset. Call IRQ handler directly
  

• * each pass as interrupt have been disabled. We always scrub for
  

• * outstanding G2H as it is possible for outstanding_submission_g2h to
  

• * be incremented after the context state update.
  

• */
  

• for (i = 0; i < 4 && atomic_read(&guc->outstanding_submission_g2h); ++i) {

• intel_guc_to_host_event_handler(guc);
  

-#define wait_for_reset(guc, wait_var) \

• intel_guc_wait_for_pending_msg(guc, wait_var, false, (HZ / 20))
  

• do {
  

• 	wait_for_reset(guc, &guc->outstanding_submission_g2h);
  

• } while (!list_empty(&guc->ct.requests.incoming));
  

• }

• flush_work(&guc->ct.requests.worker);

Same thing about flush_work as in an earlier patch. -Daniel

• scrub_guc_desc_for_outstanding_g2h(guc);

}

-- 2.32.0

On Mon, Aug 16, 2021 at 06:51:33AM -0700, Matthew Brost wrote:

A subsequent patch will flip the locking hierarchy from ce->guc_state.lock -> sched_engine->lock to sched_engine->lock -> ce->guc_state.lock. As such we need to release the submit fence for a request from an IRQ to break a lock inversion - i.e. the fence must be release went holding ce->guc_state.lock and the releasing of the can acquire sched_engine->lock.

Signed-off-by: Matthew Brost matthew.brost@intel.com

Title should be "irq work", otherwise it reads a bit strange. Also these kind of nestings would be good to document in the kerneldoc too (maybe as you go even). -Daniel

---

drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++++++++++++++- drivers/gpu/drm/i915/i915_request.h | 5 +++++ 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 8c560ed14976..9ae4633aa7cb 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -2017,6 +2017,14 @@ static const struct intel_context_ops guc_context_ops = { .create_virtual = guc_create_virtual, };

+static void submit_work_cb(struct irq_work *wrk) +{

• struct i915_request *rq = container_of(wrk, typeof(*rq), submit_work);
• might_lock(&rq->engine->sched_engine->lock);
• i915_sw_fence_complete(&rq->submit);

+}

static void __guc_signal_context_fence(struct intel_context *ce) { struct i915_request *rq; @@ -2026,8 +2034,12 @@ static void __guc_signal_context_fence(struct intel_context *ce) if (!list_empty(&ce->guc_state.fences)) trace_intel_context_fence_release(ce);

• /*

• * Use an IRQ to ensure locking order of sched_engine->lock ->
  

• * ce->guc_state.lock is preserved.
  

• */
  

  list_for_each_entry(rq, &ce->guc_state.fences, guc_fence_link)

• i915_sw_fence_complete(&rq->submit);
  

• irq_work_queue(&rq->submit_work);
  
  

  INIT_LIST_HEAD(&ce->guc_state.fences);

} @@ -2137,6 +2149,7 @@ static int guc_request_alloc(struct i915_request *rq) spin_lock_irqsave(&ce->guc_state.lock, flags); if (context_wait_for_deregister_to_register(ce) || context_pending_disable(ce)) {

• init_irq_work(&rq->submit_work, submit_work_cb);
  

  i915_sw_fence_await(&rq->submit);

  list_add_tail(&rq->guc_fence_link, &ce->guc_state.fences);

diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index 1bc1349ba3c2..d818cfbfc41d 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -218,6 +218,11 @@ struct i915_request { }; struct llist_head execute_cb; struct i915_sw_fence semaphore;

• /**

• * @submit_work: complete submit fence from an IRQ if needed for
  

• * locking hierarchy reasons.
  

• */
  

• struct irq_work submit_work;

  /*

  • A list of everyone we wait upon, and everyone who waits upon us.

-- 2.32.0

On Mon, Aug 16, 2021 at 06:51:34AM -0700, Matthew Brost wrote:

Move guc_blocked fence to struct guc_state as the lock which protects the fence lives there.

s/ce->guc_blocked/ce->guc_state.blocked_fence/g

Signed-off-by: Matthew Brost matthew.brost@intel.com

General comment, but latest when your combine your count state with a wait queue you're very far into "reinventing a mutex/semaphore, badly" land.

I think we really need to look into why we can't just protect this all with a mutex and make sure the awkward transition states are never visible to anyone else. -Daniel

---

drivers/gpu/drm/i915/gt/intel_context.c | 5 +++-- drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++--- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +++++++++--------- 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index 745e84c72c90..0e48939ec85f 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -405,8 +405,9 @@ intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine) * Initialize fence to be complete as this is expected to be complete * unless there is a pending schedule disable outstanding. */

• i915_sw_fence_init(&ce->guc_blocked, sw_fence_dummy_notify);
• i915_sw_fence_commit(&ce->guc_blocked);

• i915_sw_fence_init(&ce->guc_state.blocked_fence,

• 	   sw_fence_dummy_notify);
  

• i915_sw_fence_commit(&ce->guc_state.blocked_fence);

  i915_active_init(&ce->active, __intel_context_active, __intel_context_retire, 0);

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h index 3a73f3117873..c06171ee8792 100644 --- a/drivers/gpu/drm/i915/gt/intel_context_types.h +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h @@ -167,6 +167,8 @@ struct intel_context { * fence related to GuC submission */ struct list_head fences;

• /* GuC context blocked fence */
  

• struct i915_sw_fence blocked_fence;
  

  } guc_state;

  struct {

@@ -190,9 +192,6 @@ struct intel_context { */ struct list_head guc_id_link;

• /* GuC context blocked fence */
• struct i915_sw_fence guc_blocked;
• /*
  • GuC priority management
  */

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 9ae4633aa7cb..7aa16371908a 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -1482,24 +1482,24 @@ static void guc_blocked_fence_complete(struct intel_context *ce) { lockdep_assert_held(&ce->guc_state.lock);

• if (!i915_sw_fence_done(&ce->guc_blocked))

• i915_sw_fence_complete(&ce->guc_blocked);
  

• if (!i915_sw_fence_done(&ce->guc_state.blocked_fence))

• i915_sw_fence_complete(&ce->guc_state.blocked_fence);
  

}

static void guc_blocked_fence_reinit(struct intel_context *ce) { lockdep_assert_held(&ce->guc_state.lock);

• GEM_BUG_ON(!i915_sw_fence_done(&ce->guc_blocked));

• GEM_BUG_ON(!i915_sw_fence_done(&ce->guc_state.blocked_fence));

  /*

  • This fence is always complete unless a pending schedule disable is
  • outstanding. We arm the fence here and complete it when we receive
  • the pending schedule disable complete message.

  */

• i915_sw_fence_fini(&ce->guc_blocked);
• i915_sw_fence_reinit(&ce->guc_blocked);
• i915_sw_fence_await(&ce->guc_blocked);
• i915_sw_fence_commit(&ce->guc_blocked);

• i915_sw_fence_fini(&ce->guc_state.blocked_fence);
• i915_sw_fence_reinit(&ce->guc_state.blocked_fence);
• i915_sw_fence_await(&ce->guc_state.blocked_fence);
• i915_sw_fence_commit(&ce->guc_state.blocked_fence);

}

static u16 prep_context_pending_disable(struct intel_context *ce) @@ -1539,7 +1539,7 @@ static struct i915_sw_fence *guc_context_block(struct intel_context *ce) if (enabled) clr_context_enabled(ce); spin_unlock_irqrestore(&ce->guc_state.lock, flags);

• return &ce->guc_blocked;
  

• return &ce->guc_state.blocked_fence;
  

  }

  /*

@@ -1555,7 +1555,7 @@ static struct i915_sw_fence *guc_context_block(struct intel_context *ce) with_intel_runtime_pm(runtime_pm, wakeref) __guc_context_sched_disable(guc, ce, guc_id);

• return &ce->guc_blocked;

• return &ce->guc_state.blocked_fence;

}

static void guc_context_unblock(struct intel_context *ce)

2.32.0

On Mon, Aug 16, 2021 at 06:51:35AM -0700, Matthew Brost wrote:

Rework and simplify the locking with GuC subission. Drop sched_state_no_lock and move all fields under the guc_state.sched_state and protect all these fields with guc_state.lock . This requires changing the locking hierarchy from guc_state.lock -> sched_engine.lock to sched_engine.lock -> guc_state.lock.

Signed-off-by: Matthew Brost matthew.brost@intel.com

Yeah this is definitely going in the right direction. Especially sprinkling lockdep_assert_held around.

One comment below.

---

drivers/gpu/drm/i915/gt/intel_context_types.h | 5 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 186 ++++++++---------- drivers/gpu/drm/i915/i915_trace.h | 6 +- 3 files changed, 89 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h index c06171ee8792..d5d643b04d54 100644 --- a/drivers/gpu/drm/i915/gt/intel_context_types.h +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h @@ -161,7 +161,7 @@ struct intel_context { * sched_state: scheduling state of this context using GuC * submission */

• u16 sched_state;
  

• u32 sched_state;
  

  /*
  • fences: maintains of list of requests that have a submit
  • fence related to GuC submission

@@ -178,9 +178,6 @@ struct intel_context { struct list_head requests; } guc_active;

• /* GuC scheduling state flags that do not require a lock. */
• atomic_t guc_sched_state_no_lock;
• /* GuC LRC descriptor ID */ u16 guc_id;

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 7aa16371908a..ba19b99173fc 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -72,86 +72,23 @@ guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count);

#define GUC_REQUEST_SIZE 64 /* bytes */

-/*

• • Below is a set of functions which control the GuC scheduling state which do
• • not require a lock as all state transitions are mutually exclusive. i.e. It
• • is not possible for the context pinning code and submission, for the same
• • context, to be executing simultaneously. We still need an atomic as it is
• • possible for some of the bits to changing at the same time though.
• */

-#define SCHED_STATE_NO_LOCK_ENABLED BIT(0) -#define SCHED_STATE_NO_LOCK_PENDING_ENABLE BIT(1) -#define SCHED_STATE_NO_LOCK_REGISTERED BIT(2) -static inline bool context_enabled(struct intel_context *ce) -{

• return (atomic_read(&ce->guc_sched_state_no_lock) &

• SCHED_STATE_NO_LOCK_ENABLED);
  

-}

-static inline void set_context_enabled(struct intel_context *ce) -{

• atomic_or(SCHED_STATE_NO_LOCK_ENABLED, &ce->guc_sched_state_no_lock);

-}

-static inline void clr_context_enabled(struct intel_context *ce) -{

• atomic_and((u32)~SCHED_STATE_NO_LOCK_ENABLED,

•    &ce->guc_sched_state_no_lock);
  

-}

-static inline bool context_pending_enable(struct intel_context *ce) -{

• return (atomic_read(&ce->guc_sched_state_no_lock) &

• SCHED_STATE_NO_LOCK_PENDING_ENABLE);
  

-}

-static inline void set_context_pending_enable(struct intel_context *ce) -{

• atomic_or(SCHED_STATE_NO_LOCK_PENDING_ENABLE,

•   &ce->guc_sched_state_no_lock);
  

-}

-static inline void clr_context_pending_enable(struct intel_context *ce) -{

• atomic_and((u32)~SCHED_STATE_NO_LOCK_PENDING_ENABLE,

•    &ce->guc_sched_state_no_lock);
  

-}

-static inline bool context_registered(struct intel_context *ce) -{

• return (atomic_read(&ce->guc_sched_state_no_lock) &

• SCHED_STATE_NO_LOCK_REGISTERED);
  

-}

-static inline void set_context_registered(struct intel_context *ce) -{

• atomic_or(SCHED_STATE_NO_LOCK_REGISTERED,

•   &ce->guc_sched_state_no_lock);
  

-}

-static inline void clr_context_registered(struct intel_context *ce) -{

• atomic_and((u32)~SCHED_STATE_NO_LOCK_REGISTERED,

•    &ce->guc_sched_state_no_lock);
  

-}

/*

• Below is a set of functions which control the GuC scheduling state which

• • require a lock, aside from the special case where the functions are called
• • from guc_lrc_desc_pin(). In that case it isn't possible for any other code
• • path to be executing on the context.

• • require a lock.
  */

#define SCHED_STATE_WAIT_FOR_DEREGISTER_TO_REGISTER BIT(0) #define SCHED_STATE_DESTROYED BIT(1) #define SCHED_STATE_PENDING_DISABLE BIT(2) #define SCHED_STATE_BANNED BIT(3) -#define SCHED_STATE_BLOCKED_SHIFT 4 +#define SCHED_STATE_ENABLED BIT(4) +#define SCHED_STATE_PENDING_ENABLE BIT(5) +#define SCHED_STATE_REGISTERED BIT(6) +#define SCHED_STATE_BLOCKED_SHIFT 7 #define SCHED_STATE_BLOCKED BIT(SCHED_STATE_BLOCKED_SHIFT) #define SCHED_STATE_BLOCKED_MASK (0xfff << SCHED_STATE_BLOCKED_SHIFT) static inline void init_sched_state(struct intel_context *ce) { lockdep_assert_held(&ce->guc_state.lock);

• atomic_set(&ce->guc_sched_state_no_lock, 0); ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;

}

@@ -161,9 +98,8 @@ static inline bool sched_state_is_init(struct intel_context *ce) * XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED after * suspend. */

• return !(atomic_read(&ce->guc_sched_state_no_lock) &

•  ~SCHED_STATE_NO_LOCK_REGISTERED) &&
  

• !(ce->guc_state.sched_state &= ~SCHED_STATE_BLOCKED_MASK);
  

• return !(ce->guc_state.sched_state &=

•  ~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
  

}

static inline bool @@ -236,6 +172,57 @@ static inline void clr_context_banned(struct intel_context *ce) ce->guc_state.sched_state &= ~SCHED_STATE_BANNED; }

+static inline bool context_enabled(struct intel_context *ce)

No statice inline in .c files. The compiler is better at this than you are. Especially once you add stuff like asserts and everything, it's just not worth the cognitive effort to have to reevaluate these.

One-line helpers in headers are the only exception where static inline is ok. -Daniel

+{

• return ce->guc_state.sched_state & SCHED_STATE_ENABLED;

+}

+static inline void set_context_enabled(struct intel_context *ce) +{

• lockdep_assert_held(&ce->guc_state.lock);
• ce->guc_state.sched_state |= SCHED_STATE_ENABLED;

+}

+static inline void clr_context_enabled(struct intel_context *ce) +{

• lockdep_assert_held(&ce->guc_state.lock);
• ce->guc_state.sched_state &= ~SCHED_STATE_ENABLED;

+}

+static inline bool context_pending_enable(struct intel_context *ce) +{

• return ce->guc_state.sched_state & SCHED_STATE_PENDING_ENABLE;

+}

+static inline void set_context_pending_enable(struct intel_context *ce) +{

• lockdep_assert_held(&ce->guc_state.lock);
• ce->guc_state.sched_state |= SCHED_STATE_PENDING_ENABLE;

+}

+static inline void clr_context_pending_enable(struct intel_context *ce) +{

• lockdep_assert_held(&ce->guc_state.lock);
• ce->guc_state.sched_state &= ~SCHED_STATE_PENDING_ENABLE;

+}

+static inline bool context_registered(struct intel_context *ce) +{

• return ce->guc_state.sched_state & SCHED_STATE_REGISTERED;

+}

+static inline void set_context_registered(struct intel_context *ce) +{

• lockdep_assert_held(&ce->guc_state.lock);
• ce->guc_state.sched_state |= SCHED_STATE_REGISTERED;

+}

+static inline void clr_context_registered(struct intel_context *ce) +{

• lockdep_assert_held(&ce->guc_state.lock);
• ce->guc_state.sched_state &= ~SCHED_STATE_REGISTERED;

+}

static inline u32 context_blocked(struct intel_context *ce) { return (ce->guc_state.sched_state & SCHED_STATE_BLOCKED_MASK) >> @@ -244,7 +231,6 @@ static inline u32 context_blocked(struct intel_context *ce)

static inline void incr_context_blocked(struct intel_context *ce) {

• lockdep_assert_held(&ce->engine->sched_engine->lock); lockdep_assert_held(&ce->guc_state.lock);

  ce->guc_state.sched_state += SCHED_STATE_BLOCKED;

@@ -254,7 +240,6 @@ static inline void incr_context_blocked(struct intel_context *ce)

static inline void decr_context_blocked(struct intel_context *ce) {

• lockdep_assert_held(&ce->engine->sched_engine->lock); lockdep_assert_held(&ce->guc_state.lock);

  GEM_BUG_ON(!context_blocked(ce)); /* Underflow check */

@@ -443,6 +428,8 @@ static int guc_add_request(struct intel_guc *guc, struct i915_request *rq) u32 g2h_len_dw = 0; bool enabled;

• lockdep_assert_held(&rq->engine->sched_engine->lock);
• /*
  • Corner case where requests were sitting in the priority list or a
  • request resubmitted after the context was banned.

@@ -450,7 +437,7 @@ static int guc_add_request(struct intel_guc *guc, struct i915_request *rq) if (unlikely(intel_context_is_banned(ce))) { i915_request_put(i915_request_mark_eio(rq)); intel_engine_signal_breadcrumbs(ce->engine);

• goto out;
  

• return 0;
  

  }

  GEM_BUG_ON(!atomic_read(&ce->guc_id_ref));

@@ -463,9 +450,11 @@ static int guc_add_request(struct intel_guc *guc, struct i915_request *rq) if (unlikely(!lrc_desc_registered(guc, ce->guc_id))) { err = guc_lrc_desc_pin(ce, false); if (unlikely(err))

• 	goto out;
  

• 	return err;
  

  }

• spin_lock(&ce->guc_state.lock);

• /*

  • The request / context will be run on the hardware when scheduling
  • gets enabled in the unblock.

@@ -500,6 +489,7 @@ static int guc_add_request(struct intel_guc *guc, struct i915_request *rq) trace_i915_request_guc_submit(rq);

out:

• spin_unlock(&ce->guc_state.lock); return err;

}

@@ -720,8 +710,6 @@ void intel_guc_submission_reset_prepare(struct intel_guc *guc) spin_lock_irq(&guc_to_gt(guc)->irq_lock); spin_unlock_irq(&guc_to_gt(guc)->irq_lock);

• guc_flush_submissions(guc);

• flush_work(&guc->ct.requests.worker);

  scrub_guc_desc_for_outstanding_g2h(guc);

@@ -1125,7 +1113,11 @@ static int steal_guc_id(struct intel_guc *guc)

list_del_init(&ce->guc_id_link);
guc_id = ce->guc_id;

• spin_lock(&ce->guc_state.lock);
  

  clr_context_registered(ce);

• spin_unlock(&ce->guc_state.lock);
  

• set_context_guc_id_invalid(ce); return guc_id; } else {

@@ -1161,6 +1153,8 @@ static int pin_guc_id(struct intel_guc *guc, struct intel_context *ce) try_again: spin_lock_irqsave(&guc->contexts_lock, flags);

• might_lock(&ce->guc_state.lock);
• if (context_guc_id_invalid(ce)) { ret = assign_guc_id(guc, &ce->guc_id); if (ret)

@@ -1240,8 +1234,13 @@ static int register_context(struct intel_context *ce, bool loop) trace_intel_context_register(ce);

ret = __guc_action_register_context(guc, ce->guc_id, offset, loop);

• if (likely(!ret))

• if (likely(!ret)) {

• unsigned long flags;
  

• spin_lock_irqsave(&ce->guc_state.lock, flags);
  

  set_context_registered(ce);

• spin_unlock_irqrestore(&ce->guc_state.lock, flags);
  

• }

  return ret;

} @@ -1517,7 +1516,6 @@ static u16 prep_context_pending_disable(struct intel_context *ce) static struct i915_sw_fence *guc_context_block(struct intel_context *ce) { struct intel_guc *guc = ce_to_guc(ce);

• struct i915_sched_engine *sched_engine = ce->engine->sched_engine; unsigned long flags; struct intel_runtime_pm *runtime_pm = ce->engine->uncore->rpm; intel_wakeref_t wakeref;

@@ -1526,13 +1524,7 @@ static struct i915_sw_fence *guc_context_block(struct intel_context *ce)

spin_lock_irqsave(&ce->guc_state.lock, flags);

• /*

• * Sync with submission path, increment before below changes to context
  

• * state.
  

• */
  

• spin_lock(&sched_engine->lock); incr_context_blocked(ce);

• spin_unlock(&sched_engine->lock);

  enabled = context_enabled(ce); if (unlikely(!enabled || submission_disabled(guc))) {

@@ -1561,7 +1553,6 @@ static struct i915_sw_fence *guc_context_block(struct intel_context *ce) static void guc_context_unblock(struct intel_context *ce) { struct intel_guc *guc = ce_to_guc(ce);

• struct i915_sched_engine *sched_engine = ce->engine->sched_engine; unsigned long flags; struct intel_runtime_pm *runtime_pm = ce->engine->uncore->rpm; intel_wakeref_t wakeref;

@@ -1586,13 +1577,7 @@ static void guc_context_unblock(struct intel_context *ce) intel_context_get(ce); }

• /*

• * Sync with submission path, decrement after above changes to context
  

• * state.
  

• */
  

• spin_lock(&sched_engine->lock); decr_context_blocked(ce);

• spin_unlock(&sched_engine->lock);

  spin_unlock_irqrestore(&ce->guc_state.lock, flags);

@@ -1702,7 +1687,9 @@ static void guc_context_sched_disable(struct intel_context *ce)

if (submission_disabled(guc) || context_guc_id_invalid(ce) || !lrc_desc_registered(guc, ce->guc_id)) {

• spin_lock_irqsave(&ce->guc_state.lock, flags);
  

  clr_context_enabled(ce);

• spin_unlock_irqrestore(&ce->guc_state.lock, flags);
  

  goto unpin; }

@@ -1752,7 +1739,6 @@ static inline void guc_lrc_desc_unpin(struct intel_context *ce) GEM_BUG_ON(ce != __get_context(guc, ce->guc_id)); GEM_BUG_ON(context_enabled(ce));

• clr_context_registered(ce); deregister_context(ce, ce->guc_id, true);

}

@@ -1825,8 +1811,10 @@ static void guc_context_destroy(struct kref *kref) /* Seal race with Reset */ spin_lock_irqsave(&ce->guc_state.lock, flags); disabled = submission_disabled(guc);

• if (likely(!disabled))

• if (likely(!disabled)) { set_context_destroyed(ce);

• clr_context_registered(ce);
  

• } spin_unlock_irqrestore(&ce->guc_state.lock, flags); if (unlikely(disabled)) { release_guc_id(guc, ce);

@@ -2695,8 +2683,7 @@ int intel_guc_sched_done_process_msg(struct intel_guc *guc, (!context_pending_enable(ce) && !context_pending_disable(ce)))) { drm_err(&guc_to_gt(guc)->i915->drm,

• 	"Bad context sched_state 0x%x, 0x%x, desc_idx %u",
  

• 	atomic_read(&ce->guc_sched_state_no_lock),
  

• 	"Bad context sched_state 0x%x, desc_idx %u",
  ce->guc_state.sched_state, desc_idx);
  

  return -EPROTO; }

@@ -2711,7 +2698,9 @@ int intel_guc_sched_done_process_msg(struct intel_guc *guc, } #endif

• spin_lock_irqsave(&ce->guc_state.lock, flags);
  

  clr_context_pending_enable(ce);

• spin_unlock_irqrestore(&ce->guc_state.lock, flags);
  

  } else if (context_pending_disable(ce)) { bool banned;

@@ -2985,9 +2974,8 @@ void intel_guc_submission_print_context_info(struct intel_guc *guc, atomic_read(&ce->pin_count)); drm_printf(p, "\t\tGuC ID Ref Count: %u\n", atomic_read(&ce->guc_id_ref));

• drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
  

• 	   ce->guc_state.sched_state,
  

• 	   atomic_read(&ce->guc_sched_state_no_lock));
  

• drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
  

• 	   ce->guc_state.sched_state);
  
  

  guc_log_context_priority(p, ce); }

diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index 806ad688274b..0a77eb2944b5 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -903,7 +903,6 @@ DECLARE_EVENT_CLASS(intel_context, __field(u32, guc_id) __field(int, pin_count) __field(u32, sched_state)

• 	     __field(u32, guc_sched_state_no_lock)
       __field(u8, guc_prio)
       ),
  
  

@@ -911,15 +910,12 @@ DECLARE_EVENT_CLASS(intel_context, __entry->guc_id = ce->guc_id; __entry->pin_count = atomic_read(&ce->pin_count); __entry->sched_state = ce->guc_state.sched_state;

• 	   __entry->guc_sched_state_no_lock =
  

• 	   atomic_read(&ce->guc_sched_state_no_lock);
     __entry->guc_prio = ce->guc_prio;
     ),
  
  

•     TP_printk("guc_id=%d, pin_count=%d sched_state=0x%x,0x%x, guc_prio=%u",
  

•     TP_printk("guc_id=%d, pin_count=%d sched_state=0x%x, guc_prio=%u",
        __entry->guc_id, __entry->pin_count,
        __entry->sched_state,
  

• 	      __entry->guc_sched_state_no_lock,
        __entry->guc_prio)
  

);

-- 2.32.0

On Tue, Aug 17, 2021 at 12:27:29PM +0200, Daniel Vetter wrote:

On Mon, Aug 16, 2021 at 06:51:36AM -0700, Matthew Brost wrote:

...

Lock the xarray and take ref to the context if needed.

v2: (Checkpatch)

• Add new line after declaration

Signed-off-by: Matthew Brost matthew.brost@intel.com

.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 84 ++++++++++++++++--- 1 file changed, 73 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index ba19b99173fc..2ecb2f002bed 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -599,8 +599,18 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc) unsigned long index, flags; bool pending_disable, pending_enable, deregister, destroyed, banned;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) {

• spin_lock_irqsave(&ce->guc_state.lock, flags);
  

• /*
  

•  * Corner case where the ref count on the object is zero but and
  

•  * deregister G2H was lost. In this case we don't touch the ref
  

•  * count and finish the destroy of the context.
  

•  */
  

• bool do_put = kref_get_unless_zero(&ce->ref);
  

This looks really scary, because in another loop below you have an unconditional refcount increase. This means sometimes guc->context_lookup

Yea, good catch those loops need something like this too.

xarray guarantees we hold a full reference on the context, sometimes we don't. So we're right back in "protect the code" O(N^2) review complexity instead of invariant rules about the datastructure, which is linear.

Essentially anytime you feel like you have to add a comment to explain what's going on about concurrent stuff you're racing with, you're protecting code, not data.

Since guc can't do a hole lot without the guc_id registered and all that, I kinda expected you'd always have a full reference here. If there's

The deregister is triggered by the ref count going to zero and we can't fully release the guc_id until that operation completes hence why it is still in the xarray. I think the solution here is to use iterator like you mention below that ref counts this correctly.

intermediate stages (e.g. around unregister) where this is currently not always the case, then those should make sure a full reference is held.

Another option would be to threa ->context_lookup as a weak reference that we lazily clean up when the context is finalized. That works too, but probably not with a spinlock (since you most likely have to wait for all pending guc transations to complete), but it's another option.

Either way I think standard process is needed here for locking design, i.e.

1. come up with the right invariants ("we always have a full reference

when a context is ont he guc->context_lookup xarray") 2. come up with the locks. From the guc side the xa_lock is maybe good enough, but from the context side this doesn't protect against a re-registering racing against a deregistering. So probably needs more rules on top, and then you have a nice lock inversion in a few places like here. 3. document it and roll it out.

The other thing is that this is a very tricky iterator, and there's a few copies of it. That is, if this is the right solution. As-is this should be abstracted away into guc_context_iter_begin/next_end() helpers, e.g. like we have for drm_connector_list_iter_begin/end_next as an example.

I can check this out.

Matt

Cheers, Daniel

...

• xa_unlock(&guc->context_lookup);
  

• spin_lock(&ce->guc_state.lock);
  
  

  /*

  • Once we are at this point submission_disabled() is guaranteed

@@ -616,7 +626,9 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc) banned = context_banned(ce); init_sched_state(ce);

• spin_unlock_irqrestore(&ce->guc_state.lock, flags);
  

• spin_unlock(&ce->guc_state.lock);
  

• GEM_BUG_ON(!do_put && !destroyed);
  
  

  if (pending_enable || destroyed || deregister) { atomic_dec(&guc->outstanding_submission_g2h);

@@ -645,7 +657,12 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc)

	intel_context_put(ce);
}

• if (do_put)
  

• 	intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

  }
• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

static inline bool @@ -866,16 +883,26 @@ void intel_guc_submission_reset(struct intel_guc *guc, bool stalled) { struct intel_context *ce; unsigned long index;

• unsigned long flags;

  if (unlikely(!guc_submission_initialized(guc))) { /* Reset called during driver load? GuC not yet initialised! */ return; }

• xa_for_each(&guc->context_lookup, index, ce)

• xa_lock_irqsave(&guc->context_lookup, flags);

• xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  

• if (intel_context_is_pinned(ce)) __guc_reset_context(ce, stalled);

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

• }

• xa_unlock_irqrestore(&guc->context_lookup, flags);

• /* GuC is blown away, drop all references to contexts */ xa_destroy(&guc->context_lookup);

} @@ -950,11 +977,21 @@ void intel_guc_submission_cancel_requests(struct intel_guc *guc) { struct intel_context *ce; unsigned long index;

• unsigned long flags;
• xa_lock_irqsave(&guc->context_lookup, flags);
• xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  
  

• xa_for_each(&guc->context_lookup, index, ce) if (intel_context_is_pinned(ce)) guc_cancel_context_requests(ce);

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

• }

• xa_unlock_irqrestore(&guc->context_lookup, flags);

• guc_cancel_sched_engine_requests(guc->sched_engine);

  /* GuC is blown away, drop all references to contexts */

@@ -2848,21 +2885,26 @@ void intel_guc_find_hung_context(struct intel_engine_cs *engine) struct intel_context *ce; struct i915_request *rq; unsigned long index;

• unsigned long flags;

  /* Reset called during driver load? GuC not yet initialised! */ if (unlikely(!guc_submission_initialized(guc))) return;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  

• if (!intel_context_is_pinned(ce))

• 	continue;
  

• 	goto next;
  
  

  if (intel_engine_is_virtual(ce->engine)) { if (!(ce->engine->mask & engine->mask))

• 		continue;
  

• 		goto next;
  

  } else { if (ce->engine != engine)

• 		continue;
  

• 		goto next;
  

  }

  list_for_each_entry(rq, &ce->guc_active.requests, sched.link) {

@@ -2872,9 +2914,17 @@ void intel_guc_find_hung_context(struct intel_engine_cs *engine) intel_engine_set_hung_context(engine, ce);

	/* Can only cope with one hang at a time... */

• 	return;
  

• 	intel_context_put(ce);
  

• 	xa_lock(&guc->context_lookup);
  

• 	goto done;
  

  }

+next:

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

• }

+done:

• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

void intel_guc_dump_active_requests(struct intel_engine_cs *engine, @@ -2890,23 +2940,32 @@ void intel_guc_dump_active_requests(struct intel_engine_cs *engine, if (unlikely(!guc_submission_initialized(guc))) return;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  

• if (!intel_context_is_pinned(ce))

• 	continue;
  

• 	goto next;
  
  

  if (intel_engine_is_virtual(ce->engine)) { if (!(ce->engine->mask & engine->mask))

• 		continue;
  

• 		goto next;
  

  } else { if (ce->engine != engine)

• 		continue;
  

• 		goto next;
  

  }

  spin_lock_irqsave(&ce->guc_active.lock, flags); intel_engine_dump_active_requests(&ce->guc_active.requests, hung_rq, m); spin_unlock_irqrestore(&ce->guc_active.lock, flags);

+next:

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

  }
• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

void intel_guc_submission_print_info(struct intel_guc *guc, @@ -2960,7 +3019,9 @@ void intel_guc_submission_print_context_info(struct intel_guc *guc, { struct intel_context *ce; unsigned long index;

• unsigned long flags;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) { drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id); drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);

@@ -2979,6 +3040,7 @@ void intel_guc_submission_print_context_info(struct intel_guc *guc,

guc_log_context_priority(p, ce);

}

• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

static struct intel_context *

2.32.0

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On Tue, Aug 17, 2021 at 07:13:33PM +0200, Daniel Vetter wrote:

On Tue, Aug 17, 2021 at 08:26:28AM -0700, Matthew Brost wrote:

...

On Tue, Aug 17, 2021 at 12:27:29PM +0200, Daniel Vetter wrote:

...

On Mon, Aug 16, 2021 at 06:51:36AM -0700, Matthew Brost wrote:

...

Lock the xarray and take ref to the context if needed.

v2: (Checkpatch)

• Add new line after declaration

Signed-off-by: Matthew Brost matthew.brost@intel.com

.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 84 ++++++++++++++++--- 1 file changed, 73 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index ba19b99173fc..2ecb2f002bed 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -599,8 +599,18 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc) unsigned long index, flags; bool pending_disable, pending_enable, deregister, destroyed, banned;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) {

• spin_lock_irqsave(&ce->guc_state.lock, flags);
  

• /*
  

•  * Corner case where the ref count on the object is zero but and
  

•  * deregister G2H was lost. In this case we don't touch the ref
  

•  * count and finish the destroy of the context.
  

•  */
  

• bool do_put = kref_get_unless_zero(&ce->ref);
  

This looks really scary, because in another loop below you have an unconditional refcount increase. This means sometimes guc->context_lookup

Yea, good catch those loops need something like this too.

...

xarray guarantees we hold a full reference on the context, sometimes we don't. So we're right back in "protect the code" O(N^2) review complexity instead of invariant rules about the datastructure, which is linear.

Essentially anytime you feel like you have to add a comment to explain what's going on about concurrent stuff you're racing with, you're protecting code, not data.

Since guc can't do a hole lot without the guc_id registered and all that, I kinda expected you'd always have a full reference here. If there's

The deregister is triggered by the ref count going to zero and we can't fully release the guc_id until that operation completes hence why it is still in the xarray. I think the solution here is to use iterator like you mention below that ref counts this correctly.

Hm but if the refcount drops to zero while we have a guc_id, how does that work? Do we delay the guc_context_destroy until that's done, or is the

Yes, we don't want to release the guc_id and deregister the context with the GuC until the i915 is done with the context (no refs). We issue the deregister when we have no refs (done directly now, add worker to do this in a upcoming patch). We release the guc_id, remove from xarray, and destroy context when the deregister completes.

context handed off internally somehow to a worker?

Afaik intel_context_put is called from all kinds of nasty context, so waiting is not an option as-is ...

Right, it is definitely can be called from nasty contexts hence why move this to a work in an upcoming patch.

Matt

-Daniel

...

...

intermediate stages (e.g. around unregister) where this is currently not always the case, then those should make sure a full reference is held.

Another option would be to threa ->context_lookup as a weak reference that we lazily clean up when the context is finalized. That works too, but probably not with a spinlock (since you most likely have to wait for all pending guc transations to complete), but it's another option.

Either way I think standard process is needed here for locking design, i.e.

1. come up with the right invariants ("we always have a full reference

when a context is ont he guc->context_lookup xarray") 2. come up with the locks. From the guc side the xa_lock is maybe good enough, but from the context side this doesn't protect against a re-registering racing against a deregistering. So probably needs more rules on top, and then you have a nice lock inversion in a few places like here. 3. document it and roll it out.

The other thing is that this is a very tricky iterator, and there's a few copies of it. That is, if this is the right solution. As-is this should be abstracted away into guc_context_iter_begin/next_end() helpers, e.g. like we have for drm_connector_list_iter_begin/end_next as an example.

I can check this out.

Matt

...

Cheers, Daniel

...

• xa_unlock(&guc->context_lookup);
  

• spin_lock(&ce->guc_state.lock);
  
  

  /*

  • Once we are at this point submission_disabled() is guaranteed

@@ -616,7 +626,9 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc) banned = context_banned(ce); init_sched_state(ce);

• spin_unlock_irqrestore(&ce->guc_state.lock, flags);
  

• spin_unlock(&ce->guc_state.lock);
  

• GEM_BUG_ON(!do_put && !destroyed);
  
  

  if (pending_enable || destroyed || deregister) { atomic_dec(&guc->outstanding_submission_g2h);

@@ -645,7 +657,12 @@ static void scrub_guc_desc_for_outstanding_g2h(struct intel_guc *guc)

	intel_context_put(ce);
}

• if (do_put)
  

• 	intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

  }
• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

static inline bool @@ -866,16 +883,26 @@ void intel_guc_submission_reset(struct intel_guc *guc, bool stalled) { struct intel_context *ce; unsigned long index;

• unsigned long flags;

  if (unlikely(!guc_submission_initialized(guc))) { /* Reset called during driver load? GuC not yet initialised! */ return; }

• xa_for_each(&guc->context_lookup, index, ce)

• xa_lock_irqsave(&guc->context_lookup, flags);

• xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  

• if (intel_context_is_pinned(ce)) __guc_reset_context(ce, stalled);

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

• }

• xa_unlock_irqrestore(&guc->context_lookup, flags);

• /* GuC is blown away, drop all references to contexts */ xa_destroy(&guc->context_lookup);

} @@ -950,11 +977,21 @@ void intel_guc_submission_cancel_requests(struct intel_guc *guc) { struct intel_context *ce; unsigned long index;

• unsigned long flags;
• xa_lock_irqsave(&guc->context_lookup, flags);
• xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  
  

• xa_for_each(&guc->context_lookup, index, ce) if (intel_context_is_pinned(ce)) guc_cancel_context_requests(ce);

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

• }

• xa_unlock_irqrestore(&guc->context_lookup, flags);

• guc_cancel_sched_engine_requests(guc->sched_engine);

  /* GuC is blown away, drop all references to contexts */

@@ -2848,21 +2885,26 @@ void intel_guc_find_hung_context(struct intel_engine_cs *engine) struct intel_context *ce; struct i915_request *rq; unsigned long index;

• unsigned long flags;

  /* Reset called during driver load? GuC not yet initialised! */ if (unlikely(!guc_submission_initialized(guc))) return;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  

• if (!intel_context_is_pinned(ce))

• 	continue;
  

• 	goto next;
  
  

  if (intel_engine_is_virtual(ce->engine)) { if (!(ce->engine->mask & engine->mask))

• 		continue;
  

• 		goto next;
  

  } else { if (ce->engine != engine)

• 		continue;
  

• 		goto next;
  

  }

  list_for_each_entry(rq, &ce->guc_active.requests, sched.link) {

@@ -2872,9 +2914,17 @@ void intel_guc_find_hung_context(struct intel_engine_cs *engine) intel_engine_set_hung_context(engine, ce);

	/* Can only cope with one hang at a time... */

• 	return;
  

• 	intel_context_put(ce);
  

• 	xa_lock(&guc->context_lookup);
  

• 	goto done;
  

  }

+next:

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

• }

+done:

• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

void intel_guc_dump_active_requests(struct intel_engine_cs *engine, @@ -2890,23 +2940,32 @@ void intel_guc_dump_active_requests(struct intel_engine_cs *engine, if (unlikely(!guc_submission_initialized(guc))) return;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) {

• intel_context_get(ce);
  

• xa_unlock(&guc->context_lookup);
  

• if (!intel_context_is_pinned(ce))

• 	continue;
  

• 	goto next;
  
  

  if (intel_engine_is_virtual(ce->engine)) { if (!(ce->engine->mask & engine->mask))

• 		continue;
  

• 		goto next;
  

  } else { if (ce->engine != engine)

• 		continue;
  

• 		goto next;
  

  }

  spin_lock_irqsave(&ce->guc_active.lock, flags); intel_engine_dump_active_requests(&ce->guc_active.requests, hung_rq, m); spin_unlock_irqrestore(&ce->guc_active.lock, flags);

+next:

• intel_context_put(ce);
  

• xa_lock(&guc->context_lookup);
  

  }
• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

void intel_guc_submission_print_info(struct intel_guc *guc, @@ -2960,7 +3019,9 @@ void intel_guc_submission_print_context_info(struct intel_guc *guc, { struct intel_context *ce; unsigned long index;

• unsigned long flags;

• xa_lock_irqsave(&guc->context_lookup, flags); xa_for_each(&guc->context_lookup, index, ce) { drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id); drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);

@@ -2979,6 +3040,7 @@ void intel_guc_submission_print_context_info(struct intel_guc *guc,

guc_log_context_priority(p, ce);

}

• xa_unlock_irqrestore(&guc->context_lookup, flags);

}

static struct intel_context *

2.32.0

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

On Mon, Aug 16, 2021 at 06:51:39AM -0700, Matthew Brost wrote:

Add GuC kernel doc for all structures added thus far for GuC submission and update the main GuC submission section with the new interface details.

Signed-off-by: Matthew Brost matthew.brost@intel.com

There's quite a bit more, e.g. intel_guc_ct, which has it's own world of locking design that also doesn't feel too consistent.

---

drivers/gpu/drm/i915/gt/intel_context_types.h | 42 +++++--- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 19 +++- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 101 ++++++++++++++---- drivers/gpu/drm/i915/i915_request.h | 18 ++-- 4 files changed, 131 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h index f6989e6807f7..75d609a1bc33 100644 --- a/drivers/gpu/drm/i915/gt/intel_context_types.h +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h @@ -156,44 +156,56 @@ struct intel_context { u8 wa_bb_page; /* if set, page num reserved for context workarounds */

struct {

• /** lock: protects everything in guc_state */
  

• /** @lock: protects everything in guc_state */
  

  spinlock_t lock; /**

•  * sched_state: scheduling state of this context using GuC
  

•  * @sched_state: scheduling state of this context using GuC
  

  • submission
  */ u32 sched_state; /*

•  * fences: maintains of list of requests that have a submit
  

•  * fence related to GuC submission
  

•  * @fences: maintains a list of requests are currently being
  

•  * fenced until a GuC operation completes
  

  */ struct list_head fences;

• /* GuC context blocked fence */
  

• /**
  

•  * @blocked_fence: fence used to signal when the blocking of a
  

•  * contexts submissions is complete.
  

•  */
  

  struct i915_sw_fence blocked_fence;

• /* GuC committed requests */
  

• /** @number_committed_requests: number of committed requests */
  

  int number_committed_requests; } guc_state;

  struct {

• /** lock: protects everything in guc_active */
  

• /** @lock: protects everything in guc_active */
  

  spinlock_t lock;

Why do we have two locks spinlocks to protect guc context state?

I do understand the need for a spinlock (at least for now) because of how i915-scheduler runs in tasklet context. But beyond that we really shouldn't need more than two locks to protect context state. You still have an entire pile here, plus some atomics, plus more.

And this is on a single context, where concurrently submitting stuff really isn't a thing. I'd expect actual benchmarking would show a perf hit, since all these locks and atomics aren't free. This is at least the case with execbuf and the various i915_vma locks we currently have.

What I expect intel_context locking to be is roughly:

- One lock to protect all intel_context state. This probably should be a dma_resv_lock for a few reasons, least so we can pin state objects underneath that lock.

- A separate lock if there's anything you need to coordinate with the backend scheduler while that's running, to avoid dma_fence inversions. Right now this separate lock might need to be a spinlock because our scheduler runs in tasklets, and that might mean we need both a mutex and a spinlock here.

Anything that goes beyond that is premature optimization and kills us code complexity vise. I'd be _extremely_ surprised if an IA core cannot keep up with GuC, and therefore anything that goes beyond "one lock per object", plus/minus execution context issues like the above tasklet issue, is likely just going to slow everything down.

• /** requests: active requests on this context */
  

• /** @requests: list of active requests on this context */
  

  struct list_head requests;

• /*
  

•  * GuC priority management
  

•  */
  

• /** @guc_prio: the contexts current guc priority */
  

  u8 guc_prio;

• /**
  

•  * @guc_prio_count: a counter of the number requests inflight in
  

•  * each priority bucket
  

•  */
  

  u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM]; } guc_active;

• /* GuC LRC descriptor ID */

• /**

• * @guc_id: unique handle which is used to communicate information with
  

• * the GuC about this context, protected by guc->contexts_lock
  

• */
  

  u16 guc_id;

• /* GuC LRC descriptor reference count */

• /**

• * @guc_id_ref: the number of references to the guc_id, when
  

• * transitioning in and out of zero protected by guc->contexts_lock
  

• */
  

  atomic_t guc_id_ref;

All this guc_id related stuff (including the guc->context_lookup xarray I guess) also has quite a pile of atomics and locks.

• /*

• * GuC ID link - in list when unpinned but guc_id still valid in GuC
  

• /**

• * @guc_id_link: in guc->guc_id_list when the guc_id has no refs but is
  

• * still valid, protected by guc->contexts_lock
  

  */ struct list_head guc_id_link;

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h index 2e27fe59786b..c0b3fdb601f0 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h @@ -41,6 +41,10 @@ struct intel_guc { spinlock_t irq_lock; unsigned int msg_enabled_mask;

• /**

• * @outstanding_submission_g2h: number of outstanding G2H related to GuC
  

• * submission, used to determine if the GT is idle
  

• */
  

  atomic_t outstanding_submission_g2h;

atomic_t is good for statistcs, but not for code flow control. If you use if for that you either need a lot of barriers and comments, which means there needs to be some real perf numbers showing that this is required in a workload we care about.

Or you stuff this into a related lock. E.g. from high-level view stuff this into intel_guc_ct (which also has definitely way more locks than it needs) could make sense?

struct { @@ -49,12 +53,16 @@ struct intel_guc { void (*disable)(struct intel_guc *guc); } interrupts;

• /*

• * contexts_lock protects the pool of free guc ids and a linked list of
  

• * guc ids available to be stolen
  

• /**

• * @contexts_lock: protects guc_ids, guc_id_list, ce->guc_id, and
  

• * ce->guc_id_ref when transitioning in and out of zero
  

  */ spinlock_t contexts_lock;

• /** @guc_ids: used to allocate new guc_ids */ struct ida guc_ids;

• /**

• * @guc_id_list: list of intel_context with valid guc_ids but no refs
  

• */
  

  struct list_head guc_id_list;

  bool submission_supported;

@@ -70,7 +78,10 @@ struct intel_guc { struct i915_vma *lrc_desc_pool; void *lrc_desc_pool_vaddr;

• /* guc_id to intel_context lookup */

• /**

• * @context_lookup: used to intel_context from guc_id, if a context is
  

• * present in this structure it is registered with the GuC
  

• */
  

  struct xarray context_lookup;

  /* Control params for fw initialization */

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index eb06a4c7534e..18ef363c6e5d 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -28,21 +28,6 @@ /**

• DOC: GuC-based command submission

• • IMPORTANT NOTE: GuC submission is currently not supported in i915. The GuC
• • firmware is moving to an updated submission interface and we plan to
• • turn submission back on when that lands. The below documentation (and related
• • code) matches the old submission model and will be updated as part of the
• • upgrade to the new flow.
• • GuC stage descriptor:
• • During initialization, the driver allocates a static pool of 1024 such
• • descriptors, and shares them with the GuC. Currently, we only use one
• • descriptor. This stage descriptor lets the GuC know about the workqueue and
• • process descriptor. Theoretically, it also lets the GuC know about our HW
• • contexts (context ID, etc...), but we actually employ a kind of submission
• • where the GuC uses the LRCA sent via the work item instead. This is called
• • a "proxy" submission.
• • The Scratch registers:
  • There are 16 MMIO-based registers start from 0xC180. The kernel driver writes
  • a value to the action register (SOFT_SCRATCH_0) along with any data. It then

@@ -51,14 +36,86 @@

• processes the request. The kernel driver polls waiting for this update and
• then proceeds.

• • Work Items:
• • There are several types of work items that the host may place into a
• • workqueue, each with its own requirements and limitations. Currently only
• • WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
• • represents in-order queue. The kernel driver packs ring tail pointer and an
• • ELSP context descriptor dword into Work Item.
• • See guc_add_request()

• • Command Transport buffers (CTBs):
• • Covered in detail in other sections but CTBs (host-to-guc, H2G, guc-to-host
• • G2H) are a message interface between the i915 and GuC used to controls
• • submissions.
• • Context registration:
• • Before a context can be submitted it must be registered with the GuC via a
• • H2G. A unique guc_id is associated with each context. The context is either
• • registered at request creation time (normal operation) or at submission time
• • (abnormal operation, e.g. after a reset).
• • Context submission:
• • The i915 updates the LRC tail value in memory. Either a schedule enable H2G
• • or context submit H2G is used to submit a context.
• • Context unpin:
• • To unpin a context a H2G is used to disable scheduling and when the
• • corresponding G2H returns indicating the scheduling disable operation has
• • completed it is safe to unpin the context. While a disable is in flight it
• • isn't safe to resubmit the context so a fence is used to stall all future
• • requests until the G2H is returned.
• • Context deregistration:
• • Before a context can be destroyed or we steal its guc_id we must deregister
• • the context with the GuC via H2G. If stealing the guc_id it isn't safe to
• • submit anything to this guc_id until the deregister completes so a fence is
• • used to stall all requests associated with this guc_ids until the
• • corresponding G2H returns indicating the guc_id has been deregistered.
• • guc_ids:
• • Unique number associated with private GuC context data passed in during
• • context registration / submission / deregistration. 64k available. Simple ida
• • is used for allocation.
• • Stealing guc_ids:
• • If no guc_ids are available they can be stolen from another context at
• • request creation time if that context is unpinned. If a guc_id can't be found
• • we punt this problem to the user as we believe this is near impossible to hit
• • during normal use cases.
• • Locking:
• • In the GuC submission code we have 4 basic spin locks which protect
• • everything. Details about each below.
• • sched_engine->lock
• • This is the submission lock for all contexts that share a i915 schedule
• • engine (sched_engine), thus only 1 context which share a sched_engine can be
• • submitting at a time. Currently only 1 sched_engine used for all of GuC
• • submission but that could change in the future.

There's at least 3 more spinlocks for intel_guc_ct ...

• • guc->contexts_lock
• • Protects guc_id allocation. Global lock i.e. Only 1 context that uses GuC
• • submission can hold this at a time.

Plus you forgot the spinlock of the xarrray, which is also used in the code with this patch set, not just internally in the xarray, so we have to think about that one too.

Iow still way too many locks.

• • ce->guc_state.lock
• • Protects everything under ce->guc_state. Ensures that a context is in the
• • correct state before issuing a H2G. e.g. We don't issue a schedule disable
• • on disabled context (bad idea), we don't issue schedule enable when a
• • schedule disable is inflight, etc... Lock individual to each context.
• • ce->guc_active.lock
• • Protects everything under ce->guc_active which is the current requests
• • inflight on the context / priority management. Lock individual to each
• • context.
• • Lock ordering rules:
• • sched_engine->lock -> ce->guc_active.lock
• • sched_engine->lock -> ce->guc_state.lock
• • guc->contexts_lock -> ce->guc_state.lock
• • Reset races:
• • When a GPU full reset is triggered it is assumed that some G2H responses to
• • a H2G can be lost as the GuC is likely toast. Losing these G2H can prove to
• • fatal as we do certain operations upon receiving a G2H (e.g. destroy
• • contexts, release guc_ids, etc...). Luckly when this occurs we can scrub
• • context state and cleanup appropriately, however this is quite racey. To
• • avoid races the rules are check for submission being disabled (i.e. check for
• • mid reset) with the appropriate lock being held. If submission is disabled
• • don't send the H2G or update the context state. The reset code must disable
• • submission and grab all these locks before scrubbing for the missing G2H.

Can we make this all a lot less racy? Instead of a huge state machinery can't we just do all that under a context look, i.e.

1. take context lock 2. send guc message that is tricky, like register or deregister or whatever 3. wait for that reply, our context is blocked anyway, no harm holding a lock, other contexts can keep processing 4. the lower-level guc_ct code guarantees that we either get the reply, or a -ERESET or whatever indicating that we raced with a reset, in which case we can just restart whatever it is we wanted to do (or for deregister, do nothing since the guc reset has solved that problem) 5. unlock

Massively lockless state machines are cool, but also very hard to maintain and keep correct. -Daniel

*/

/* GuC Virtual Engine */ diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index d818cfbfc41d..177eaf55adff 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -290,18 +290,20 @@ struct i915_request { struct hrtimer timer; } watchdog;

• /*

• * Requests may need to be stalled when using GuC submission waiting for
  

• * certain GuC operations to complete. If that is the case, stalled
  

• * requests are added to a per context list of stalled requests. The
  

• * below list_head is the link in that list.
  

• /**

• * @guc_fence_link: Requests may need to be stalled when using GuC
  

• * submission waiting for certain GuC operations to complete. If that is
  

• * the case, stalled requests are added to a per context list of stalled
  

• * requests. The below list_head is the link in that list. Protected by
  

• * ce->guc_state.lock.
  

  */ struct list_head guc_fence_link;

  /**

• * Priority level while the request is inflight. Differs from i915
  

• * scheduler priority. See comment above
  

• * I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP for details.
  

• * @guc_prio: Priority level while the request is inflight. Differs from
  

• * i915 scheduler priority. See comment above
  

• * I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP for details. Protected by
  

• * ce->guc_active.lock.
  

  */

#define GUC_PRIO_INIT 0xff

#define GUC_PRIO_FINI 0xfe

2.32.0

On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:

On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:

...

On Mon, Aug 16, 2021 at 06:51:39AM -0700, Matthew Brost wrote:

...

Add GuC kernel doc for all structures added thus far for GuC submission and update the main GuC submission section with the new interface details.

Signed-off-by: Matthew Brost matthew.brost@intel.com

There's quite a bit more, e.g. intel_guc_ct, which has it's own world of locking design that also doesn't feel too consistent.

That is a different layer than GuC submission so I don't we should mention anything about that layer here. Didn't really write that layer and it super painful to touch that code so I'm going to stay out of any rework you think we need to do there.

Well there's three locks there plus it leaks out (you have your outstanding_submission_g2h atomic_t which is very closed tied to well, outstanding guc transmissions), so I guess I need someone else for that?

...

...

---

drivers/gpu/drm/i915/gt/intel_context_types.h | 42 +++++--- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 19 +++- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 101 ++++++++++++++---- drivers/gpu/drm/i915/i915_request.h | 18 ++-- 4 files changed, 131 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h index f6989e6807f7..75d609a1bc33 100644 --- a/drivers/gpu/drm/i915/gt/intel_context_types.h +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h @@ -156,44 +156,56 @@ struct intel_context { u8 wa_bb_page; /* if set, page num reserved for context workarounds */

struct {

• /** lock: protects everything in guc_state */
  

• /** @lock: protects everything in guc_state */
  

  spinlock_t lock; /**

•  * sched_state: scheduling state of this context using GuC
  

•  * @sched_state: scheduling state of this context using GuC
  

  • submission
  */ u32 sched_state; /*

•  * fences: maintains of list of requests that have a submit
  

•  * fence related to GuC submission
  

•  * @fences: maintains a list of requests are currently being
  

•  * fenced until a GuC operation completes
  

  */ struct list_head fences;

• /* GuC context blocked fence */
  

• /**
  

•  * @blocked_fence: fence used to signal when the blocking of a
  

•  * contexts submissions is complete.
  

•  */
  

  struct i915_sw_fence blocked_fence;

• /* GuC committed requests */
  

• /** @number_committed_requests: number of committed requests */
  

  int number_committed_requests; } guc_state;

  struct {

• /** lock: protects everything in guc_active */
  

• /** @lock: protects everything in guc_active */
  

  spinlock_t lock;

Why do we have two locks spinlocks to protect guc context state?

I do understand the need for a spinlock (at least for now) because of how i915-scheduler runs in tasklet context. But beyond that we really shouldn't need more than two locks to protect context state. You still have an entire pile here, plus some atomics, plus more.

Yea I actually thought about this after I sent to out, guc_active & guc_state should be combined into a single lock. Originally I had two different locks because of old hierarchy this is no longer needed. Can fix.

...

And this is on a single context, where concurrently submitting stuff really isn't a thing. I'd expect actual benchmarking would show a perf hit, since all these locks and atomics aren't free. This is at least the case with execbuf and the various i915_vma locks we currently have.

What I expect intel_context locking to be is roughly:

• One lock to protect all intel_context state. This probably should be a dma_resv_lock for a few reasons, least so we can pin state objects underneath that lock.

• A separate lock if there's anything you need to coordinate with the backend scheduler while that's running, to avoid dma_fence inversions. Right now this separate lock might need to be a spinlock because our scheduler runs in tasklets, and that might mean we need both a mutex and a spinlock here.

Anything that goes beyond that is premature optimization and kills us code complexity vise. I'd be _extremely_ surprised if an IA core cannot keep up with GuC, and therefore anything that goes beyond "one lock per object", plus/minus execution context issues like the above tasklet issue, is likely just going to slow everything down.

If I combine the above spin lock, isn't that basically what we have one lock for the context state as it relates to GuC submission?

Also thinking when we move to DRM scheduler we likely can get rid of all the atomic contexts in the GuC submission backend.

...

...

• /** requests: active requests on this context */
  

• /** @requests: list of active requests on this context */
  

  struct list_head requests;

• /*
  

•  * GuC priority management
  

•  */
  

• /** @guc_prio: the contexts current guc priority */
  

  u8 guc_prio;

• /**
  

•  * @guc_prio_count: a counter of the number requests inflight in
  

•  * each priority bucket
  

•  */
  

  u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM]; } guc_active;

• /* GuC LRC descriptor ID */

• /**

• * @guc_id: unique handle which is used to communicate information with
  

• * the GuC about this context, protected by guc->contexts_lock
  

• */
  

  u16 guc_id;

• /* GuC LRC descriptor reference count */

• /**

• * @guc_id_ref: the number of references to the guc_id, when
  

• * transitioning in and out of zero protected by guc->contexts_lock
  

• */
  

  atomic_t guc_id_ref;

All this guc_id related stuff (including the guc->context_lookup xarray I guess) also has quite a pile of atomics and locks.

...

• /*

• * GuC ID link - in list when unpinned but guc_id still valid in GuC
  

• /**

• * @guc_id_link: in guc->guc_id_list when the guc_id has no refs but is
  

• * still valid, protected by guc->contexts_lock
  

  */ struct list_head guc_id_link;

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h index 2e27fe59786b..c0b3fdb601f0 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h @@ -41,6 +41,10 @@ struct intel_guc { spinlock_t irq_lock; unsigned int msg_enabled_mask;

• /**

• * @outstanding_submission_g2h: number of outstanding G2H related to GuC
  

• * submission, used to determine if the GT is idle
  

• */
  

  atomic_t outstanding_submission_g2h;

atomic_t is good for statistcs, but not for code flow control. If you use if for that you either need a lot of barriers and comments, which means there needs to be some real perf numbers showing that this is required in a workload we care about.

This is kinda stat too, it is connected to debugfs and typically is non-zero if something has gone horribly wrong (e.g. you lose a G2H). Confused about the flow control comment, this basically it just sayings the GT isn't idle if the GuC is processing messages and we expect a G2H response. A counter here makes sense to me and don't see why we'd need barriorr for this.

Yeah but if you actually use it in the code (which I thought you do), and not just for debugfs stats, then you have control flow that depends upon this counter. Which means you need memory barriers, or that stuff will be unordered against other code that's running.

...

Or you stuff this into a related lock. E.g. from high-level view stuff this into intel_guc_ct (which also has definitely way more locks than it needs) could make sense?

I had it in that layer at one point but got push back, thus it lives here now. The way it is used now it probably makes sense to keep it here.

Hm can you dig out that push back? Often when locking rolls in it makes it pretty clear that the layering needs to be rethought. Not changing that code because it's written already or something like that, and then working that suboptimal locking in your area isn't great. Minimally we need a plan (like we have one for drm/scheduler for the frontend stuff) and someone who'll do it. -Daniel

...

...

struct { @@ -49,12 +53,16 @@ struct intel_guc { void (*disable)(struct intel_guc *guc); } interrupts;

• /*

• * contexts_lock protects the pool of free guc ids and a linked list of
  

• * guc ids available to be stolen
  

• /**

• * @contexts_lock: protects guc_ids, guc_id_list, ce->guc_id, and
  

• * ce->guc_id_ref when transitioning in and out of zero
  

  */ spinlock_t contexts_lock;

• /** @guc_ids: used to allocate new guc_ids */ struct ida guc_ids;

• /**

• * @guc_id_list: list of intel_context with valid guc_ids but no refs
  

• */
  

  struct list_head guc_id_list;

  bool submission_supported;

@@ -70,7 +78,10 @@ struct intel_guc { struct i915_vma *lrc_desc_pool; void *lrc_desc_pool_vaddr;

• /* guc_id to intel_context lookup */

• /**

• * @context_lookup: used to intel_context from guc_id, if a context is
  

• * present in this structure it is registered with the GuC
  

• */
  

  struct xarray context_lookup;

  /* Control params for fw initialization */

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index eb06a4c7534e..18ef363c6e5d 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -28,21 +28,6 @@ /**

• DOC: GuC-based command submission

• • IMPORTANT NOTE: GuC submission is currently not supported in i915. The GuC
• • firmware is moving to an updated submission interface and we plan to
• • turn submission back on when that lands. The below documentation (and related
• • code) matches the old submission model and will be updated as part of the
• • upgrade to the new flow.
• • GuC stage descriptor:
• • During initialization, the driver allocates a static pool of 1024 such
• • descriptors, and shares them with the GuC. Currently, we only use one
• • descriptor. This stage descriptor lets the GuC know about the workqueue and
• • process descriptor. Theoretically, it also lets the GuC know about our HW
• • contexts (context ID, etc...), but we actually employ a kind of submission
• • where the GuC uses the LRCA sent via the work item instead. This is called
• • a "proxy" submission.
• • The Scratch registers:
  • There are 16 MMIO-based registers start from 0xC180. The kernel driver writes
  • a value to the action register (SOFT_SCRATCH_0) along with any data. It then

@@ -51,14 +36,86 @@

• processes the request. The kernel driver polls waiting for this update and
• then proceeds.

• • Work Items:
• • There are several types of work items that the host may place into a
• • workqueue, each with its own requirements and limitations. Currently only
• • WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
• • represents in-order queue. The kernel driver packs ring tail pointer and an
• • ELSP context descriptor dword into Work Item.
• • See guc_add_request()

• • Command Transport buffers (CTBs):
• • Covered in detail in other sections but CTBs (host-to-guc, H2G, guc-to-host
• • G2H) are a message interface between the i915 and GuC used to controls
• • submissions.
• • Context registration:
• • Before a context can be submitted it must be registered with the GuC via a
• • H2G. A unique guc_id is associated with each context. The context is either
• • registered at request creation time (normal operation) or at submission time
• • (abnormal operation, e.g. after a reset).
• • Context submission:
• • The i915 updates the LRC tail value in memory. Either a schedule enable H2G
• • or context submit H2G is used to submit a context.
• • Context unpin:
• • To unpin a context a H2G is used to disable scheduling and when the
• • corresponding G2H returns indicating the scheduling disable operation has
• • completed it is safe to unpin the context. While a disable is in flight it
• • isn't safe to resubmit the context so a fence is used to stall all future
• • requests until the G2H is returned.
• • Context deregistration:
• • Before a context can be destroyed or we steal its guc_id we must deregister
• • the context with the GuC via H2G. If stealing the guc_id it isn't safe to
• • submit anything to this guc_id until the deregister completes so a fence is
• • used to stall all requests associated with this guc_ids until the
• • corresponding G2H returns indicating the guc_id has been deregistered.
• • guc_ids:
• • Unique number associated with private GuC context data passed in during
• • context registration / submission / deregistration. 64k available. Simple ida
• • is used for allocation.
• • Stealing guc_ids:
• • If no guc_ids are available they can be stolen from another context at
• • request creation time if that context is unpinned. If a guc_id can't be found
• • we punt this problem to the user as we believe this is near impossible to hit
• • during normal use cases.
• • Locking:
• • In the GuC submission code we have 4 basic spin locks which protect
• • everything. Details about each below.
• • sched_engine->lock
• • This is the submission lock for all contexts that share a i915 schedule
• • engine (sched_engine), thus only 1 context which share a sched_engine can be
• • submitting at a time. Currently only 1 sched_engine used for all of GuC
• • submission but that could change in the future.

There's at least 3 more spinlocks for intel_guc_ct ...

Different layer that I'd like to stay out of.

...

...

• • guc->contexts_lock
• • Protects guc_id allocation. Global lock i.e. Only 1 context that uses GuC
• • submission can hold this at a time.

Plus you forgot the spinlock of the xarrray, which is also used in the code with this patch set, not just internally in the xarray, so we have to think about that one too.

Iow still way too many locks.

Well we can delete one pretty easily, that's something, right?

...

...

• • ce->guc_state.lock
• • Protects everything under ce->guc_state. Ensures that a context is in the
• • correct state before issuing a H2G. e.g. We don't issue a schedule disable
• • on disabled context (bad idea), we don't issue schedule enable when a
• • schedule disable is inflight, etc... Lock individual to each context.
• • ce->guc_active.lock
• • Protects everything under ce->guc_active which is the current requests
• • inflight on the context / priority management. Lock individual to each
• • context.
• • Lock ordering rules:
• • sched_engine->lock -> ce->guc_active.lock
• • sched_engine->lock -> ce->guc_state.lock
• • guc->contexts_lock -> ce->guc_state.lock
• • Reset races:
• • When a GPU full reset is triggered it is assumed that some G2H responses to
• • a H2G can be lost as the GuC is likely toast. Losing these G2H can prove to
• • fatal as we do certain operations upon receiving a G2H (e.g. destroy
• • contexts, release guc_ids, etc...). Luckly when this occurs we can scrub
• • context state and cleanup appropriately, however this is quite racey. To
• • avoid races the rules are check for submission being disabled (i.e. check for
• • mid reset) with the appropriate lock being held. If submission is disabled
• • don't send the H2G or update the context state. The reset code must disable
• • submission and grab all these locks before scrubbing for the missing G2H.

Can we make this all a lot less racy? Instead of a huge state machinery can't we just do all that under a context look, i.e.

Well can't sleep inside the context lock so confused by this suggestion.

...

1. take context lock
2. send guc message that is tricky, like register or deregister or

whatever

A schedule enable is tricky too and that can be sent from the submission path.

...

3. wait for that reply, our context is blocked anyway, no harm holding a

We don't need to block while a schedule enable is in flight. Also we only block the submissions while the other messages are in flight, we are allowed continuing working on the context (e.g. we can generate a prep another request while the operation is inflight).

...

lock, other contexts can keep processing 4. the lower-level guc_ct code guarantees that we either get the reply, or

Again don't really want to touch the guc_ct code.

...

a -ERESET or whatever indicating that we raced with a reset, in which case we can just restart whatever it is we wanted to do (or for deregister, do nothing since the guc reset has solved that problem)

You'd still have to have a list of waiters which get woke on a reset too. Not all the convinced this would simplier that checking if a reset is in flight within a lock.

...

5. unlock

Massively lockless state machines are cool, but also very hard to maintain and keep correct.

Not saying we can't try to make this simplier over time but a huge structural change at this point is way more likely to break things than cleaning up what we have in place.

Matt

...

-Daniel

...

*/

/* GuC Virtual Engine */ diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index d818cfbfc41d..177eaf55adff 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -290,18 +290,20 @@ struct i915_request { struct hrtimer timer; } watchdog;

• /*

• * Requests may need to be stalled when using GuC submission waiting for
  

• * certain GuC operations to complete. If that is the case, stalled
  

• * requests are added to a per context list of stalled requests. The
  

• * below list_head is the link in that list.
  

• /**

• * @guc_fence_link: Requests may need to be stalled when using GuC
  

• * submission waiting for certain GuC operations to complete. If that is
  

• * the case, stalled requests are added to a per context list of stalled
  

• * requests. The below list_head is the link in that list. Protected by
  

• * ce->guc_state.lock.
  

  */ struct list_head guc_fence_link;

  /**

• * Priority level while the request is inflight. Differs from i915
  

• * scheduler priority. See comment above
  

• * I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP for details.
  

• * @guc_prio: Priority level while the request is inflight. Differs from
  

• * i915 scheduler priority. See comment above
  

• * I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP for details. Protected by
  

• * ce->guc_active.lock.
  

  */

#define GUC_PRIO_INIT 0xff

#define GUC_PRIO_FINI 0xfe

2.32.0

-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch