Skip to content

Cache handling / PAT settings / MOCS table

https://lore.kernel.org/all/Y9hw0sSC58B32yPg@mdroper-desk1.amr.corp.intel.com/

  • /* FIXME: vfunc + pass in caching rules */
  • if (xe->info.platform == XE_METEORLAKE) {
  •       pte |= MTL_GGTT_PTE_PAT0;                                                                                                                                                                                                      
  •       pte |= MTL_GGTT_PTE_PAT1;
  • }

This hardcodes PAT index 3, which is WB with 1-way coherency. That's
probably how a lot of UMD buffers will get mapped in the PPGTT, but may
not be suitable in all cases. There are some workarounds that require
uncached in certain circumstances, and I think display generally wants
uncached for the GGTT mapping.

We need to figure out how cache behavior is going to be managed on the
Xe driver in general. i915's mutable obj->cache_level is generally
considered a big mistake now; I think the expectation was that we were
going to track PAT index selection on the VMA now since that matches how
the hardware tracks it and you can potentially have multiple mappings
with different PAT settings.

and

+#define GEN8_PPAT_LLC (1<<2)

The ones above here aren't even used anywhere below.

+#define GEN8_PPAT_WB (3<<0)
+#define GEN8_PPAT_WT (2<<0)
+#define GEN8_PPAT_WC (1<<0)
+#define GEN8_PPAT_UC (0<<0)
+#define GEN8_PPAT_ELLC_OVERRIDE (0<<2)

Also unused

+#define GEN8_PPAT(i, x) ((u64)(x) << ((i) * 8))

Ditto

+#define GEN12_PPAT_CLOS(x) ((x)<<2)

Only used on PVC, so this should have an XEHPC_ prefix rather than
GEN12_.

and

  • xe_mmio_write32(gt, GEN12_PAT_INDEX(2).reg,
  •               MTL_PPAT_3_UC | MTL_2_COH_1W);

Indices 1 and 2 shouldn't have the 1W coherency bit set.

All of the register writes here should be switched to MCR writes in
general to avoid racing with external agents who might be trying to
perform unicast operations.

and

  • MOCS_ENTRY(XE_MOCS_PTE,
  •          LE_0_PAGETABLE | LE_TC_0_PAGETABLE,                                                                                                                                                                                         
  •          L3_1_UC),
  • GEN11_MOCS_ENTRIES,

I think this entry is something we got stuck with on TGL because we
screwed up the table and couldn't fix it after force_probe was removed
for ABI reasons. But for the Xe driver we should just use the correct
table (which I believe is already handled by the "gen12" table farther
down); no need to repeat our i915 mistakes.

and

...

  • case XE_METEORLAKE:
  •       info->size = ARRAY_SIZE(dg2_mocs_desc);                                                                                                                                                                                        
  •       info->table = dg2_mocs_desc;

We still need to land the proper MTL-specific table here.

...

+void xe_mocs_init(struct xe_gt *gt)
+{

In general it seems like we might be able to convert the MOCS
programming over to use the RTP facility of the Xe driver?

and

  • /* FIXME: I don't think the PPAT handling is correct for MTL */

Yeah, the PAT encoding for MTL needs updates. But also, I think the
enum xe_cache_level is something we probably want to rethink. That's
similar to what i915 did, which is causing us all kinds of headaches
now. For PPGTT mappings, userspace should already know exactly what PAT
behavior they want (just like they know what MOCS behavior they want)
and they can pass us the specific index to encode (presumably at vm_bind
time so that it's attached to the specific gtt mapping, not the object).

Edited by Rodrigo Vivi