[Intel-xe] [PATCH v4 0/5] PAT and cache coherency support

[Souza, Jose]

On Wed, 2023-09-27 at 12:00 +0100, Matthew Auld wrote:
> Branch available here:
> https://gitlab.freedesktop.org/mwa/kernel/-/tree/xe-pat-index?ref_type=heads
> 
> Series directly depends on the patches here:
> https://patchwork.freedesktop.org/series/124225/
> 
> Goal here is to allow userspace to directly control the pat_index when mapping
> memory via the ppGTT, in addtion to the CPU caching mode. This is very much
> needed on newer igpu platforms which allow incoherent GT access, where the
> choice over the cache level and expected coherency is best left to userspace
> depending on their usecase.  In the future there may also be other stuff encoded
> in the pat_index, so giving userspace direct control will also be needed there.
> 
> To support this we added new gem_create uAPI for selecting the CPU cache
> mode to use for system memory, including the expected GPU coherency mode. There
> are various restrictions here for the selected coherency mode and compatible CPU
> cache modes.  With that in place the actual pat_index can now be provided as
> part of vm_bind. The only restriction is that the coherency mode of the
> pat_index must be at least as coherent as the gem_create coherency mode. There
> are also some special cases like with userptr and dma-buf.
> 
> v2:
>   - Loads of improvements/tweaks. Main changes are to now allow
>     gem_create.coh_mode <= coh_mode(pat_index), rather than it needing to match
>     exactly. This simplifies the dma-buf policy from userspace pov. Also we now
>     only consider COH_NONE and COH_AT_LEAST_1WAY.
> v3:
>   - Rebase. Split the pte_encode() refactoring, plus various smaller tweaks and
>     fixes.
> v4:
>   - Rebase on Lucas' new series.
>   - Drop UC cache mode.
>   - s/smem_cpu_caching/cpu_caching/. Idea is to make VRAM WC explicit in the
>     uapi, plus make it more future proof.
> 

Thanks for the smem_cpu_caching to cpu_caching change.

This latest version is causing a GuC fw load failure in MTL, I have bisected and it is caused by "drm/xe: directly use pat_index for pte_encode".

[  173.995308] xe 0000:00:02.0: [drm:xe_guc_init [xe]] GuC param[12] = 0x00000000
[  173.995388] xe 0000:00:02.0: [drm:xe_guc_init [xe]] GuC param[13] = 0x00000000
[  173.995467] xe 0000:00:02.0: [drm:xe_wopcm_init [xe]] WOPCM: 4096K
[  173.995609] xe 0000:00:02.0: [drm:xe_wopcm_init [xe]] GuC WOPCM is already locked [2048K, 832K)
[  174.234667] xe 0000:00:02.0: [drm] GuC load failed: status = 0x80007134
[  174.234681] xe 0000:00:02.0: [drm] GuC load failed: status: Reset = 0, BootROM = 0x1A, UKernel = 0x71, MIA = 0x00, Auth = 0x02
[  174.234690] xe 0000:00:02.0: [drm] 0xcabba9e6 0xdeadfeed 0x00000000 0x00000078
[  174.234697] xe 0000:00:02.0: [drm] 0x00010000 0x00000000 0x0000fff0 0x00000000
[  174.234703] xe 0000:00:02.0: [drm] 0x00000002 0xcabba9e6 0x8086dead 0x00000000
[  174.234709] xe 0000:00:02.0: [drm] 0x00000000 0x00002000 0x00000000 0x00002000
[  174.234714] xe 0000:00:02.0: [drm] 0x00000000 0x00000002 0xcabba9f6 0xbeeffeed
[  174.234719] xe 0000:00:02.0: [drm] 0x00000000 0x00000000 0x00004000 0x00000000
[  174.234724] xe 0000:00:02.0: [drm] 0x00004000 0x00000000 0x00000002 0x8086900d
[  174.234730] xe 0000:00:02.0: [drm] 0x00010000 0x00000006 0x00010001 0x00460606
[  174.234735] xe 0000:00:02.0: [drm] 0x00020001 0x00004050 0x00030001 0x00004b00
[  174.234741] xe 0000:00:02.0: [drm] 0x00000000 0x00000000 0x00000000 0x00000000


uAPI wise it need some renames to follow with the uAPI alignment series(https://patchwork.freedesktop.org/series/124271/) take a look at
https://patchwork.freedesktop.org/patch/559576/?series=124271&rev=1
https://patchwork.freedesktop.org/patch/559577/?series=124271&rev=1