All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Krzysztof Niemiec" <krzysztof.niemiec@intel.com>,
	dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 5/5] drm/i915/selftests: Port selftests that access ggtt to work with multi-gt
Date: Thu, 29 Oct 2026 01:51:08 +0000	[thread overview]
Message-ID: <sashiko-outbox-188621@kernel.org> (raw)
In-Reply-To: <20261029014155.55865-6-krzysztof.niemiec@intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] drm/i915/selftests: partial per-GT resume in igt_pm_resume()
- [Medium] drm/i915/selftests: wrong GGTT pinned in igt_vma_remapped_gtt()
--

commit 8db2f33415f217cdf07f8583781cb2c2c4d93d25
Author: Krzysztof Niemiec <krzysztof.niemiec@intel.com>

drm/i915/selftests: Port selftests that access ggtt to work with multi-gt

This patch updates several i915 live selftests in i915_gem_client_blt.c,
i915_gem.c, and i915_vma.c to iterate over each GT via for_each_gt() and
intel_gt_live_subtests() instead of referencing to_gt(i915)->ggtt directly.

> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c b/drivers/gpu/drm/i915/selftests/i915_gem.c
> index ad650f67114a6..8f72fd1af8d61 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem.c

[ ... ]

> @@ -99,29 +100,29 @@ static int igt_pm_prepare(struct drm_i915_private *i915)
>  	return 0;
>  }
>  
> -static void igt_pm_suspend(struct drm_i915_private *i915)
> +static void igt_pm_suspend(struct intel_gt *gt)
>  {
>  	intel_wakeref_t wakeref;
>  
> -	with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> -		i915_ggtt_suspend(to_gt(i915)->ggtt);
> -		i915_gem_suspend_late(i915);
> +	with_intel_runtime_pm(&gt->i915->runtime_pm, wakeref) {
> +		i915_ggtt_suspend(gt->ggtt);
> +		i915_gem_suspend_late(gt->i915);
>  	}
>  }
>  
> -static void igt_pm_hibernate(struct drm_i915_private *i915)
> +static void igt_pm_hibernate(struct intel_gt *gt)
>  {
>  	intel_wakeref_t wakeref;
>  
> -	with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> -		i915_ggtt_suspend(to_gt(i915)->ggtt);
> +	with_intel_runtime_pm(&gt->i915->runtime_pm, wakeref) {
> +		i915_ggtt_suspend(gt->ggtt);
>  
> -		i915_gem_freeze(i915);
> -		i915_gem_freeze_late(i915);
> +		i915_gem_freeze(gt->i915);
> +		i915_gem_freeze_late(gt->i915);
>  	}
>  }
>  
> -static void igt_pm_resume(struct drm_i915_private *i915)
> +static void igt_pm_resume(struct intel_gt *gt)
>  {
>  	intel_wakeref_t wakeref;
>  
> @@ -129,17 +130,18 @@ static void igt_pm_resume(struct drm_i915_private *i915)
>  	 * Both suspend and hibernate follow the same wakeup path and assume
>  	 * that runtime-pm just works.
>  	 */
> -	with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
> -		i915_ggtt_resume(to_gt(i915)->ggtt);
> -		if (GRAPHICS_VER(i915) >= 8)
> -			setup_private_pat(to_gt(i915));
> -		i915_gem_resume(i915);
> +	with_intel_runtime_pm(&gt->i915->runtime_pm, wakeref) {
> +		i915_ggtt_resume(gt->ggtt);
> +		if (GRAPHICS_VER(gt->i915) >= 8)
> +			setup_private_pat(gt);
> +		i915_gem_resume(gt->i915);
>  	}
>  }

[Severity: Medium]
Does converting igt_gem_suspend() and igt_gem_hibernate() into per-GT
subtests via intel_gt_live_subtests() leave non-target GTs with
unconfigured private PAT registers and unresumed GGTT mappings while
device-wide GEM suspend and resume still reset and submit work to all GTs?

In igt_gem_suspend() and igt_gem_hibernate(), live_context(i915, file)
creates a context with engines across all GTs, and switch_to_context(ctx)
submits requests across every engine on all GTs.

Similarly, the GEM suspend/resume helpers operate across all GTs on the
device:

  igt_pm_prepare()
    -> i915_gem_suspend()
      -> for_each_gt() intel_gt_suspend_prepare(gt)
  igt_pm_suspend()
    -> i915_gem_suspend_late()
      -> for_each_gt() intel_gt_suspend_late(gt)
  igt_pm_resume()
    -> i915_gem_resume()
      -> for_each_gt() intel_gt_resume(gt)

However, igt_pm_suspend(), igt_pm_hibernate(), and igt_pm_resume() only
call i915_ggtt_suspend(gt->ggtt), i915_ggtt_resume(gt->ggtt), and
setup_private_pat(gt) on the single gt passed to the subtest. By contrast,
i915_drm_resume() in drivers/gpu/drm/i915/i915_driver.c programs the
private PAT for every GT before calling i915_gem_resume():

  for_each_gt(gt, dev_priv, i)
      if (GRAPHICS_VER(gt->i915) >= 8)
          setup_private_pat(gt);

On multi-GT platforms, sanitizing and resetting all GTs while only calling
setup_private_pat(gt) and i915_ggtt_resume(gt->ggtt) on one GT leaves the
other GTs without private PAT setup (and without GGTT/GuC mapping resume if
the GTs have separate GGTTs) when i915_gem_resume() and
switch_to_context(ctx) execute across all GTs.

In addition, running i915_gem_live_selftests() in a for_each_gt() loop via
intel_gt_live_subtests() only waits for idle on a single GT in
__intel_gt_live_setup() and redundantly runs the GT-independent
igt_gem_ww_ctx() test once per GT. Should i915_gem_live_selftests() remain
a device-level i915_live_subtests() run and iterate for_each_gt() inside
igt_pm_suspend(), igt_pm_hibernate(), igt_pm_resume(), and trash_stolen()
instead?

> diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c b/drivers/gpu/drm/i915/selftests/i915_vma.c
> index fc068dab27f44..3231025a7b7fa 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> @@ -957,7 +957,8 @@ int i915_vma_mock_selftests(void)
>  
>  static int igt_vma_remapped_gtt(void *arg)
>  {
> -	struct drm_i915_private *i915 = arg;
> +	struct intel_gt *gt = arg;
> +	struct drm_i915_private *i915 = gt->i915;
>  	const struct intel_remapped_plane_info planes[] = {
>  		{ .width = 1, .height = 1, .src_stride = 1 },
>  		{ .width = 2, .height = 2, .src_stride = 2 },
> @@ -990,7 +991,7 @@ static int igt_vma_remapped_gtt(void *arg)
>  	intel_wakeref_t wakeref;
>  	int err = 0;
>  
> -	if (!i915_ggtt_has_aperture(to_gt(i915)->ggtt))
> +	if (!i915_ggtt_has_aperture(gt->ggtt))
>  		return 0;
>  
>  	obj = i915_gem_object_create_internal(i915, 10 * 10 * PAGE_SIZE);

[Severity: Medium]
In igt_vma_remapped_gtt(), the aperture check is updated to inspect
gt->ggtt, but doesn't the body of the loop still pin into
to_gt(i915)->ggtt?

Later in igt_vma_remapped_gtt(), the object is pinned twice using
i915_gem_object_ggtt_pin():

  vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, PIN_MAPPABLE);
  ...
  vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);

i915_gem_object_ggtt_pin() calls i915_gem_object_ggtt_pin_ww() with
ggtt = NULL, which defaults to to_gt(i915)->ggtt:

  drivers/gpu/drm/i915/i915_gem.c:i915_gem_object_ggtt_pin_ww() {
      struct drm_i915_private *i915 = to_i915(obj->base.dev);
      struct i915_ggtt *ggtt = to_gt(i915)->ggtt;

      if (_ggtt)
          ggtt = _ggtt;
      ...
  }

If a non-primary GT has its own GGTT, igt_vma_remapped_gtt() will still
bind and map through to_gt(i915)->ggtt (or fail with -E2BIG if
to_gt(i915)->ggtt has a smaller aperture than gt->ggtt). Should those two
calls use i915_gem_object_ggtt_pin_ww(obj, NULL, gt->ggtt, ...) so that
gt->ggtt is actually used?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029014155.55865-1-krzysztof.niemiec@intel.com?part=5

  reply	other threads:[~2026-10-29  1:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29  1:41 [RFC 0/5] Selftests fixes for multi-gt platforms in i915 Krzysztof Niemiec
2026-10-29  1:41 ` [RFC 1/5] drm/i915/selftests: Port GT-dependent selftests to work with multi-GT (low-hanging fruits part 1) Krzysztof Niemiec
2026-10-29  2:09   ` sashiko-bot
2026-10-29  1:41 ` [RFC 2/5] drm/i915/selftests: Port GT-dependent selftests to work with multi-GT (low-hanging fruits part 2) Krzysztof Niemiec
2026-10-29  1:56   ` sashiko-bot
2026-10-29  1:41 ` [RFC 3/5] drm/i915/selftests: Port i915_gem_gtt.c selftest file to multi-gt Krzysztof Niemiec
2026-10-29  1:41 ` [RFC 4/5] drm/i915/sefltests: Port i915_gem_context.c " Krzysztof Niemiec
2026-10-29  1:41 ` [RFC 5/5] drm/i915/selftests: Port selftests that access ggtt to work with multi-gt Krzysztof Niemiec
2026-10-29  1:51   ` sashiko-bot [this message]
2026-10-29  2:40 ` ✗ i915.CI.BAT: failure for Selftests fixes for multi-gt platforms in i915 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=sashiko-outbox-188621@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=krzysztof.niemiec@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.