From: Matthew Brost <matthew.brost@intel.com>
To: "Summers, Stuart" <stuart.summers@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: Move page fault init after topology init
Date: Fri, 11 Jul 2025 09:58:15 -0700 [thread overview]
Message-ID: <aHFCp0zFPBVVRZoR@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <0197b86d80323ffdf6501ffc1329d2736b7bfbd7.camel@intel.com>
On Fri, Jul 11, 2025 at 10:50:44AM -0600, Summers, Stuart wrote:
> On Fri, 2025-07-11 at 16:29 +0000, Summers, Stuart wrote:
> > On Fri, 2025-07-11 at 09:25 -0700, Matthew Brost wrote:
> > > On Fri, Jul 11, 2025 at 09:08:55AM -0600, Summers, Stuart wrote:
> > > > On Thu, 2025-07-10 at 12:12 -0700, Matthew Brost wrote:
> > > > > We need the topology to determine GT page fault queue size,
> > > > > move
> > > > > page
> > > > > fault init after topology init.
> > > > >
> > > > > Cc: stable@vger.kernel.org
> > > > > Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page
> > > > > fault
> > > > > queue size")
> > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > >
> > > > Yep, good catch and thanks!
> > > >
> > >
> > > Thanks, I feel like this worked at one point in time though. Maybe
> > > something in xe_gt_init got re-ordered recently. Will check on that
> > > ahead of merging to make I have the fixes tag correct.
> >
> > You know it could have been a problem all along too...
> >
> > (num_eus + XE_NUM_HW_ENGINES) * PF_MSG_LEN_DW * PF_MULTIPLIER;
> >
> > We do have a non-zero calculation here even when num_eus is 0. That
> > might also explain why we needed that extra multiplier, even if we
> > aren't covering the full pathological case here - I still need to get
> > those pow-of-2 fixes in to that pathological patch and get that
> > merged
> > :(
>
> You know it also wouldn't hurt to print this calculated value out
> during driver load or something so we can more easily catch
> miscalculations like this instead of just relying on the compliance
> test results. Of course not needed here in this patch...
>
Indeed. I'm looking at a page fault layer refactor (similar to the TLB
invalidation layer refactor) and have some local patches. I've added an
assertion that the number of EUs calculated is non-zero, along with a
debug print statement to catch a bug like this. I could just post those
changes I suppose.
Matt
> Thanks,
> Stuart
>
> >
> > Thanks,
> > Stuart
> >
> > >
> > > Matt
> > >
> > > > Reviewed-by: Stuart Summers <stuart.summers@intel.com>
> > > >
> > > > > ---
> > > > > drivers/gpu/drm/xe/xe_gt.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/xe/xe_gt.c
> > > > > b/drivers/gpu/drm/xe/xe_gt.c
> > > > > index d397df056e4c..af03e19ef9be 100644
> > > > > --- a/drivers/gpu/drm/xe/xe_gt.c
> > > > > +++ b/drivers/gpu/drm/xe/xe_gt.c
> > > > > @@ -628,15 +628,15 @@ int xe_gt_init(struct xe_gt *gt)
> > > > > if (err)
> > > > > return err;
> > > > >
> > > > > - err = xe_gt_pagefault_init(gt);
> > > > > + err = xe_gt_sysfs_init(gt);
> > > > > if (err)
> > > > > return err;
> > > > >
> > > > > - err = xe_gt_sysfs_init(gt);
> > > > > + err = gt_init_with_gt_forcewake(gt);
> > > > > if (err)
> > > > > return err;
> > > > >
> > > > > - err = gt_init_with_gt_forcewake(gt);
> > > > > + err = xe_gt_pagefault_init(gt);
> > > > > if (err)
> > > > > return err;
> > > > >
> > > >
> >
>
prev parent reply other threads:[~2025-07-11 16:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 19:12 [PATCH] drm/xe: Move page fault init after topology init Matthew Brost
2025-07-10 19:17 ` ✓ CI.KUnit: success for " Patchwork
2025-07-10 19:20 ` [PATCH] " Cavitt, Jonathan
2025-07-10 19:54 ` ✓ Xe.CI.BAT: success for " Patchwork
2025-07-11 1:36 ` ✓ Xe.CI.Full: " Patchwork
2025-07-11 15:08 ` [PATCH] " Summers, Stuart
2025-07-11 16:25 ` Matthew Brost
2025-07-11 16:29 ` Summers, Stuart
2025-07-11 16:50 ` Summers, Stuart
2025-07-11 16:58 ` Matthew Brost [this message]
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=aHFCp0zFPBVVRZoR@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=stuart.summers@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: link
Be 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.