From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Michal Wajdeczko <michal.wajdeczko@intel.com>
Subject: Re: [PATCH] drm/xe/ggtt: clear reserved area at GUC_GGTT_TOP.
Date: Wed, 3 Jun 2026 16:11:37 +0300 [thread overview]
Message-ID: <aiAoCSGEOzHxwwMd@intel.com> (raw)
In-Reply-To: <80f3d370-7211-437f-a4d1-ef246eb47b7b@linux.intel.com>
On Wed, Jun 03, 2026 at 02:57:48PM +0200, Maarten Lankhorst wrote:
> Hello,
>
> On 5/27/26 16:45, Rodrigo Vivi wrote:
> > The PF GGTT allocator was initialised over a relative [0, usable_size)
> > range, with ggtt->start added on every address conversion to get the
> > actual hardware address. Two consequences of that model were considered
> > "horrible hacks":
> >
> > - ggtt->start (the WOPCM offset) had to be carried around and added
> > to every drm_mm result.
> This is still the case, only we add a separate variable now that is usually 0.
> We always have to ensure that this is correctly accounted
> for, otherwise we get subtle bugs, so there's no reason not to use it,
> if it's already used everywhere.
>
> Whether it's 0 or wopcm_start doesn't change the result.
>
> > - The GUC_GGTT_TOP ceiling silently truncated the GGTT range instead
> > of being made explicit, leaving PTEs in [GUC_GGTT_TOP, total_size)
> > untouched during the initial clear.
> This is a valid concern, but it's very easily be fixed inside the initial clear
> by calling xe_ggtt_clear once more with a comment for !VF case.
>
> Something like below is enough to fix it. Adding a reserved region at the end/start
> is not the way to do so and just adds more complications.
> ---8<---
> When initialising GGTT, we never clear the part above GUC_GGTT_TOP.
> Add a member to &xe_ggtt that holds the full GGTT size, and clear it
> during the pass at xe_ggtt_initial_clear.
>
> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
> ---
> diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c
> index 8ec23862477fc..497b99a932f0d 100644
> --- a/drivers/gpu/drm/xe/xe_ggtt.c
> +++ b/drivers/gpu/drm/xe/xe_ggtt.c
> @@ -115,6 +115,8 @@ struct xe_ggtt {
> u64 start;
> /** @size: Total usable size of this GGTT */
> u64 size;
> + /** @entire_size: complete size of the accessible GGTT, reserved regions inclusive */
> + u64 entire_size;
> /**
> * @flags: Flags for this GGTT.
> * Acceptable flags:
> @@ -406,7 +408,8 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
> return -ENOMEM;
> }
> ggtt_start = wopcm;
> - ggtt_size = (gsm_size / 8) * (u64)XE_PAGE_SIZE - ggtt_start;
> + ggtt->entire_size = (gsm_size / 8) * (u64)XE_PAGE_SIZE;
> + ggtt_size = ggtt->entire_size - ggtt_start;
> } else {
> ggtt_start = xe_tile_sriov_vf_ggtt_base(ggtt->tile);
> ggtt_size = xe_tile_sriov_vf_ggtt(ggtt->tile);
> @@ -417,6 +420,7 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt)
> ggtt_start, ggtt_start + ggtt_size - 1);
> return -ERANGE;
> }
> + ggtt->entire_size = ggtt_size;
> }
>
> ggtt->gsm = ggtt->tile->mmio.regs + SZ_8M;
> @@ -461,6 +465,10 @@ static void xe_ggtt_initial_clear(struct xe_ggtt *ggtt)
> drm_mm_for_each_hole(hole, &ggtt->mm, start, end)
> xe_ggtt_clear(ggtt, ggtt->start + start, end - start);
>
> + end = ggtt->start + ggtt->size;
> + if (ggtt->entire_size > end)
> + xe_ggtt_clear(ggtt, end, ggtt->entire_size - end);
You'll need the same thing for the 0 to ggtt->start range.
> +
> xe_ggtt_invalidate(ggtt);
> mutex_unlock(&ggtt->lock);
> }
--
Ville Syrjälä
Intel
prev parent reply other threads:[~2026-06-03 13:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-27 14:45 [PATCH] drm/xe/ggtt: use full-range drm_mm with reserved nodes on PF Rodrigo Vivi
2026-05-27 15:48 ` ✗ i915.CI.BAT: failure for " Patchwork
2026-05-27 17:42 ` ✓ CI.KUnit: success " Patchwork
2026-05-27 18:55 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-28 1:47 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-05-28 22:11 ` [PATCH] " Michal Wajdeczko
2026-05-28 22:28 ` Rodrigo Vivi
2026-05-29 10:50 ` Ville Syrjälä
2026-05-29 21:03 ` Rodrigo Vivi
2026-06-03 13:19 ` Ville Syrjälä
2026-06-03 13:44 ` Rodrigo Vivi
2026-06-03 14:54 ` Ville Syrjälä
2026-06-03 12:57 ` [PATCH] drm/xe/ggtt: clear reserved area at GUC_GGTT_TOP Maarten Lankhorst
2026-06-03 13:11 ` Ville Syrjälä [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=aiAoCSGEOzHxwwMd@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=rodrigo.vivi@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.