From: Matthew Brost <matthew.brost@intel.com> To: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 15/18] drm/i915/guc: Ensure H2G buffer updates visible before tail update Date: Wed, 26 May 2021 10:58:18 -0700 [thread overview] Message-ID: <20210526175818.GB31459@sdutt-i7> (raw) In-Reply-To: <3d18d63d-8359-5ce0-0320-104436d57198@intel.com> On Wed, May 26, 2021 at 02:36:18PM +0200, Michal Wajdeczko wrote: > > > On 26.05.2021 08:42, Matthew Brost wrote: > > Ensure H2G buffer updates are visible before descriptor tail updates by > > inserting a barrier between the H2G buffer update and the tail. The > > barrier is simple wmb() for SMEM and is register write for LMEM. This is > > needed if more than 1 H2G can be inflight at once. > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> > > --- > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > index fb875d257536..42063e1c355d 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > @@ -328,6 +328,18 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct) > > return ++ct->requests.last_fence; > > } > > > > +static void write_barrier(struct intel_guc_ct *ct) { > > + struct intel_guc *guc = ct_to_guc(ct); > > + struct intel_gt *gt = guc_to_gt(guc); > > + > > + if (i915_gem_object_is_lmem(guc->ct.vma->obj)) { > > + GEM_BUG_ON(guc->send_regs.fw_domains); > > + intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0); > > hmm, as this is one of the GuC scratch registers used for H2G MMIO > communication, writing 0 there might be interpreted by the GuC as new > request with action=0 and might results in extra processing/logging on > GuC side, and, since from here we don't protect access to this register > by send_mutex, we can corrupt other MMIO message being prepared from > different thread, ... can't we use other register ? > Hmm, this code has been internal for a long time and we haven't seen an issues. MMIOs are always attempted to be processed each interrupt and then CTBs are processed next. A value a 0 in scratch0 results in no MMIOs being processed as a value of 0 is a reserved action which translates to a NOP. Also in the current i915 once CTBs are enabled MMIOs are never used. That being said, I think once we transition to the new interface + enable suspend on a VF MMIOs might be used. With that I purpose that we merge this as is with a comment saying if we ever mix CTBs and MMIOs we need to find another MMIO register. I don't changing this now is worth delaying upstreaming this and also any change we make now will make us lose confidence in code that has been thoroughly tested. Matt > > + } else { > > + wmb(); > > + } > > +} > > + > > /** > > * DOC: CTB Host to GuC request > > * > > @@ -411,6 +423,12 @@ static int ct_write(struct intel_guc_ct *ct, > > } > > GEM_BUG_ON(tail > size); > > > > + /* > > + * make sure H2G buffer update and LRC tail update (if this triggering a > > + * submission) are visible before updating the descriptor tail > > + */ > > + write_barrier(ct); > > + > > /* now update desc tail (back in bytes) */ > > desc->tail = tail * 4; > > return 0; > >
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com> To: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 15/18] drm/i915/guc: Ensure H2G buffer updates visible before tail update Date: Wed, 26 May 2021 10:58:18 -0700 [thread overview] Message-ID: <20210526175818.GB31459@sdutt-i7> (raw) In-Reply-To: <3d18d63d-8359-5ce0-0320-104436d57198@intel.com> On Wed, May 26, 2021 at 02:36:18PM +0200, Michal Wajdeczko wrote: > > > On 26.05.2021 08:42, Matthew Brost wrote: > > Ensure H2G buffer updates are visible before descriptor tail updates by > > inserting a barrier between the H2G buffer update and the tail. The > > barrier is simple wmb() for SMEM and is register write for LMEM. This is > > needed if more than 1 H2G can be inflight at once. > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> > > --- > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > index fb875d257536..42063e1c355d 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > @@ -328,6 +328,18 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct) > > return ++ct->requests.last_fence; > > } > > > > +static void write_barrier(struct intel_guc_ct *ct) { > > + struct intel_guc *guc = ct_to_guc(ct); > > + struct intel_gt *gt = guc_to_gt(guc); > > + > > + if (i915_gem_object_is_lmem(guc->ct.vma->obj)) { > > + GEM_BUG_ON(guc->send_regs.fw_domains); > > + intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0); > > hmm, as this is one of the GuC scratch registers used for H2G MMIO > communication, writing 0 there might be interpreted by the GuC as new > request with action=0 and might results in extra processing/logging on > GuC side, and, since from here we don't protect access to this register > by send_mutex, we can corrupt other MMIO message being prepared from > different thread, ... can't we use other register ? > Hmm, this code has been internal for a long time and we haven't seen an issues. MMIOs are always attempted to be processed each interrupt and then CTBs are processed next. A value a 0 in scratch0 results in no MMIOs being processed as a value of 0 is a reserved action which translates to a NOP. Also in the current i915 once CTBs are enabled MMIOs are never used. That being said, I think once we transition to the new interface + enable suspend on a VF MMIOs might be used. With that I purpose that we merge this as is with a comment saying if we ever mix CTBs and MMIOs we need to find another MMIO register. I don't changing this now is worth delaying upstreaming this and also any change we make now will make us lose confidence in code that has been thoroughly tested. Matt > > + } else { > > + wmb(); > > + } > > +} > > + > > /** > > * DOC: CTB Host to GuC request > > * > > @@ -411,6 +423,12 @@ static int ct_write(struct intel_guc_ct *ct, > > } > > GEM_BUG_ON(tail > size); > > > > + /* > > + * make sure H2G buffer update and LRC tail update (if this triggering a > > + * submission) are visible before updating the descriptor tail > > + */ > > + write_barrier(ct); > > + > > /* now update desc tail (back in bytes) */ > > desc->tail = tail * 4; > > return 0; > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-05-26 18:05 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-26 6:42 [PATCH 00/18] Non-interface changing GuC CTBs updates Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Non-interface changing GuC CTBs updates (rev2) Patchwork 2021-05-27 17:13 ` John Harrison 2021-05-27 17:09 ` Matthew Brost 2021-05-26 6:42 ` [PATCH 01/18] drm/i915/guc: skip disabling CTBs before sanitizing the GuC Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 02/18] drm/i915/guc: use probe_error log for CT enablement failure Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 03/18] drm/i915/guc: enable only the user interrupt when using GuC submission Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 04/18] drm/i915/guc: Remove sample_forcewake h2g action Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 05/18] drm/i915/guc: Keep strict GuC ABI definitions Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 06/18] drm/i915/guc: Drop guc->interrupts.enabled Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-27 17:17 ` John Harrison 2021-05-27 17:17 ` John Harrison 2021-05-27 17:13 ` Matthew Brost 2021-05-27 17:13 ` Matthew Brost 2021-05-26 6:42 ` [PATCH 07/18] drm/i915/guc: Stop using fence/status from CTB descriptor Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 08/18] drm/i915: Promote ptrdiff() to i915_utils.h Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 09/18] drm/i915/guc: Only rely on own CTB size Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 10/18] drm/i915/guc: Don't repeat CTB layout calculations Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 11/18] drm/i915/guc: Replace CTB array with explicit members Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 12/18] drm/i915/guc: Update sizes of CTB buffers Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 13/18] drm/i915/guc: Relax CTB response timeout Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 12:25 ` Michal Wajdeczko 2021-05-26 12:25 ` [Intel-gfx] " Michal Wajdeczko 2021-05-26 17:38 ` Matthew Brost 2021-05-26 17:38 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 14/18] drm/i915/guc: Start protecting access to CTB descriptors Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 15/18] drm/i915/guc: Ensure H2G buffer updates visible before tail update Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 12:36 ` Michal Wajdeczko 2021-05-26 12:36 ` [Intel-gfx] " Michal Wajdeczko 2021-05-26 17:58 ` Matthew Brost [this message] 2021-05-26 17:58 ` Matthew Brost 2021-05-28 1:13 ` John Harrison 2021-05-28 1:13 ` John Harrison 2021-05-28 6:52 ` Michal Wajdeczko 2021-05-28 6:52 ` Michal Wajdeczko 2021-05-26 6:42 ` [PATCH 16/18] drm/i915/guc: Stop using mutex while sending CTB messages Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 17/18] drm/i915/guc: Don't receive all G2H messages in irq handler Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:42 ` [PATCH 18/18] drm/i915/guc: Always copy CT message to new allocation Matthew Brost 2021-05-26 6:42 ` [Intel-gfx] " Matthew Brost 2021-05-26 6:43 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Non-interface changing GuC CTBs updates (rev2) Patchwork 2021-05-27 17:13 ` John Harrison 2021-05-27 17:08 ` Matthew Brost 2021-05-26 7:11 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork 2021-05-26 9:47 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210526175818.GB31459@sdutt-i7 \ --to=matthew.brost@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=michal.wajdeczko@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.