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

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Thu, 2026-09-03 at 11:50 +0000, sashiko-bot@kernel.org wrote:
> 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.

MTL is not officially supported by the xe driver, however an additional
fix for MTL is in the pipeline.

/Thomas


> --
> 
> 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?