All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Stuart Summers" <stuart.summers@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 06/11] drm/xe: Do not claim flat CCS without a graphics IP
Date: Wed, 11 Nov 2026 03:21:28 +0000	[thread overview]
Message-ID: <sashiko-outbox-208170@kernel.org> (raw)
In-Reply-To: <20261110231442.218721-19-stuart.summers@intel.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [High] drm/xe: clearing has_flat_ccs in xe_info_init() enables AuxCCS
  on media GT
- [Medium] drm/xe: xe_info_init() leaves has_flat_ccs set when primary
  GT is disabled
--

commit f555718484d7a834cd43df271a384a71adacc98b
Author: Stuart Summers <stuart.summers@intel.com>

drm/xe: Do not claim flat CCS without a graphics IP

This commit clears xe->info.has_flat_ccs in xe_info_init() when the
device has no graphics IP descriptor.

> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index b3e5c025677cf..e4220cb0cc298 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -1106,6 +1106,14 @@ static int xe_info_init(struct xe_device *xe,
>  		xe->info.has_ctx_tlb_inval = graphics_desc->has_ctx_tlb_inval;
>  		xe->info.has_usm = graphics_desc->has_usm;
>  		xe->info.has_64bit_timestamp = graphics_desc->has_64bit_timestamp;
> +	} else {
> +		/*
> +		 * Flat CCS comes from the device descriptor rather than from
> +		 * the graphics IP, but it is still a graphics feature: its
> +		 * layout is read back through the primary GT, which is not
> +		 * there to be read.
> +		 */
> +		xe->info.has_flat_ccs = 0;
>  	}
>  
>  	if (xe->info.platform != XE_PVC)

[Severity: High]
Does clearing xe->info.has_flat_ccs when graphics_desc is NULL cause
has_aux_ccs() to return true on Xe2+ platforms without a graphics IP?

When graphics_ip is absent, GRAPHICS_VERx100(xe) is 0, so has_aux_ccs()
falls through to return !xe->info.has_flat_ccs:

drivers/gpu/drm/xe/xe_ring_ops.c:has_aux_ccs() {
	if (GRAPHICS_VERx100(xe) >= 1270 || xe->info.platform == XE_PVC)
		return false;

	return !xe->info.has_flat_ccs;
}

During media GT initialization on Xe2+ platforms without a graphics IP,
xe_ring_ops_get() then selects auxccs_ring_ops_gen12_video_decode and
auxccs_ring_ops_gen12_video_enhance, emitting unsupported Gen12 AuxCCS
register invalidations and semaphore waits (VD0_AUX_INV and VE0_AUX_INV)
on every video and page-table migration job.

[Severity: Medium]
What happens when the hardware has a graphics IP (so graphics_desc is
non-NULL), but the primary GT is disabled via configfs
(gt_types_allowed=media, as enabled by commit "drm/xe: Allow probe
without a primary GT" and commit "drm/xe: Document that
gt_types_allowed=media now probes")?

In that configuration, alloc_primary_gt() returns NULL while
xe->info.has_flat_ccs remains 1.  On discrete platforms with Flat CCS,
xe_vram_probe() -> tile_vram_size() then calls
get_flat_ccs_offset(tile->primary_gt, ...) with a NULL gt pointer and
dereferences it in gt_to_xe() and gt_to_fw().  On integrated platforms
with Flat CCS, leaving has_flat_ccs set without a primary GT keeps
xe_bo_needs_ccs_pages() and handle_system_ccs active in xe_bo_move() even
though xe_migrate_can_blit() is false.

Also, the commit message attributes the primary GT layout read to
probe_has_flat_ccs(), which only checks XE2_FLAT_CCS_ENABLE and returns 0
early when xe_root_mmio_gt(xe) is NULL; the layout read is in
tile_vram_size() -> get_flat_ccs_offset().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261110231442.218721-13-stuart.summers@intel.com?part=6

  reply	other threads:[~2026-11-11  3:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-10 23:14 [PATCH 00/11] Allow boot with only media GT Stuart Summers
2026-11-10 23:14 ` [PATCH 01/11] drm/xe: Detect each GMD_ID IP in a loop Stuart Summers
2026-11-10 23:14 ` [PATCH 02/11] drm/xe: Tolerate a missing graphics IP in xe_info_init() Stuart Summers
2026-11-10 23:14 ` [PATCH 03/11] drm/xe: Verify IP presence against GU_CNTL Stuart Summers
2026-11-10 23:14 ` [PATCH 04/11] drm/xe: Guard per-tile primary GT accesses Stuart Summers
2026-11-10 23:14 ` [PATCH 05/11] drm/xe: Stop assuming the root tile has a primary GT Stuart Summers
2026-11-11  2:59   ` sashiko-bot
2026-11-10 23:14 ` [PATCH 06/11] drm/xe: Do not claim flat CCS without a graphics IP Stuart Summers
2026-11-11  3:21   ` sashiko-bot [this message]
2026-11-10 23:14 ` [PATCH 07/11] drm/xe: Run page table updates on the media GT when there is no primary Stuart Summers
2026-11-11  3:53   ` sashiko-bot
2026-11-10 23:14 ` [PATCH 08/11] drm/xe: Document that gt_types_allowed=media now probes Stuart Summers
2026-11-10 23:14 ` [PATCH 09/11] drm/xe: Fall back to CPU copies when the tile cannot blit Stuart Summers
2026-11-11  4:25   ` sashiko-bot
2026-11-10 23:14 ` [PATCH 10/11] drm/xe: Require a fully visible VRAM BAR without a primary GT Stuart Summers
2026-11-11  4:38   ` sashiko-bot
2026-11-10 23:14 ` [PATCH 11/11] drm/xe: Allow probe " Stuart Summers
2026-11-11  4:57   ` sashiko-bot
2026-11-10 23:39 ` ✓ CI.KUnit: success for Allow boot with only media GT Patchwork
2026-11-11  0:14 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-11  4:17 ` ✓ Xe.CI.FULL: " Patchwork
2026-11-12 12:21 ` [PATCH 00/11] " Piotr Piórkowski

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-208170@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --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.