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

[Matthew Auld <matthew.auld@intel.com>]

On 03/09/2026 12:45, Thomas Hellström wrote:
> emit_render_cache_flush() sets PIPE_CONTROL0_HDC_PIPELINE_FLUSH to
> flush the L2/HDC data cache before fence signalling, but it never
> requests a flush of the LSC untyped L1 data cache via the 'Untyped
> Data-Port Cache Flush Enable' bit in PIPE_CONTROL DWord0[11].
> 
> Per the Bspec, in 3D pipeline mode HDC Pipeline Flush is documented to
> also flush/invalidate the untyped L1 cache, but only depending on how
> HDC_CHICKEN0[13:11] is programmed. Starting with MTL, this coupling
> between HDC Pipeline Flush and the untyped L1 cache flush no longer
> holds in practice, regardless of how HDC_CHICKEN0 is programmed, so
> relying on it is not safe on newer platforms such as BMG. Mesa's Vulkan
> driver (anv) has been assuming the kernel flushes both caches between
> submissions, and hit user-visible corruption in apps such as Llama.cpp
> because of this gap; it now works around it by flushing both caches
> again from userspace at the end of every command buffer.
> 
> Correctness between submissions on the same queue is userspace's
> responsibility and belongs in Mesa, not the kernel. However, for
> security we must ensure stale data can't leak through the untyped L1
> dataport cache once memory is reclaimed or evicted, which requires the
> KMD to flush it before releasing memory for reuse.
> 
> Prior to MTL, HDC_CHICKEN0 could be programmed (as already done for
> DG2 via Wa_22010960976/Wa_14013347512) to reliably keep HDC Pipeline
> Flush coupled to the untyped L1 cache flush, so those platforms are
> unaffected. Mesa's own anv driver found that on MTL the HW
> disconnected the two independently of how HDC_CHICKEN0 is programmed,
> and could not bring the old behavior back even by writing the register
> by hand; see Mesa commit 7c2ff46a4fc3 ("anv: don't prevent L1 untyped
> cache flush in 3D mode"). The kernel can't reliably request the flush
> from the CS on MTL either, so restrict the new PIPE_CONTROL bit to
> GRAPHICS_VERx100 >= 2000 (Xe2 and later), where it can be relied on.
> 
> Explicitly set PIPE_CONTROL0_UNTYPED_DATAPORT_CACHE_FLUSH together
> with PIPE_CONTROL0_HDC_PIPELINE_FLUSH in emit_render_cache_flush() on
> Xe2 and later, so the L1 data cache is known clean before memory is
> released for reuse, without depending on undocumented
> platform-specific HDC_CHICKEN0 behavior.
> 
> Bspec: 56551
> Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/7c2ff46a4fc3e537573ac9503057e0cd29b6fff3
> Fixes: 9f8f93bee3ef ("drm/xe: Emit a render cache flush after each rcs/ccs batch")
> Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/8909
> Cc: José Roberto de Souza <jose.souza@intel.com>
> Cc: intel-xe@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v6.8+
> Assisted-by: GitHub_Copilot:claude-sonnet-5
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> #v1

Reviewed-by: Matthew Auld <matthew.auld@intel.com>