Re: [PATCH v2] drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unmitigated cross-process information leak via L1 dataport cache on MTL platforms.
--

commit 9a1c38c27d115c29ae7f3e8c47d4fe8e892e8d64
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>

drm/xe: Flush LSC untyped L1 dataport cache after rcs/ccs batches

This commit introduces an explicit flush of the LSC untyped L1 dataport cache
via PIPE_CONTROL in emit_render_cache_flush() for Xe2 and later platforms. It
addresses an issue where the L1 dataport cache was not reliably coupled to the
HDC Pipeline Flush starting from MTL. By explicitly setting this bit on
GRAPHICS_VERx100(xe) >= 2000, it aims to prevent stale data leaks when memory
is reclaimed.

Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909

> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c
> index 39a670e91ba72..08b4a4283e96a 100644
> --- a/drivers/gpu/drm/xe/xe_ring_ops.c
> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c
[ ... ]
> @@ -220,6 +221,16 @@ static int emit_render_cache_flush(struct xe_sched_job *job, u32 *dw, int i)
>  				      LRC_PPHWSP_FLUSH_INVAL_SCRATCH_ADDR, 0);
>  
>  	flags0 = PIPE_CONTROL0_HDC_PIPELINE_FLUSH;
> +	/*
> +	 * Prior to MTL, HDC Pipeline Flush reliably also flushes the LSC
> +	 * untyped L1 dataport cache, provided HDC_CHICKEN0 is programmed
> +	 * correctly. Starting with MTL that coupling no longer holds
> +	 * regardless of how HDC_CHICKEN0 is programmed, but explicitly
> +	 * requesting the flush via PIPE_CONTROL is itself only reliable
> +	 * from Xe2 onward, so only gate it in on Xe2+.
> +	 */
> +	if (GRAPHICS_VERx100(xe) >= 2000)
> +		flags0 |= PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH;

[Severity: High]
This isn't a bug introduced by this patch, but does this condition leave
MTL platforms vulnerable to a cross-process information leak?

Since GRAPHICS_VERx100(xe) < 2000 for MTL platforms, they will not receive
the L1 dataport cache flush here. If the command streamer (CS) flush is
unreliable on MTL, does this mean sensitive data can still be read from the L1
cache by another process after memory is reclaimed or evicted?

If the PIPE_CONTROL method cannot be relied on for MTL, is an alternative
mitigation strategy, such as dummy shaders or MMIO-based flushes, needed to
fully resolve the vulnerability on those platforms?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903114552.48634-1-thomas.hellstrom@linux.intel.com?part=1