Quoting Kumar Valsan, Prathap (2019-10-21 14:52:12)
> On Sat, Oct 19, 2019 at 12:20:18AM +0100, Chris Wilson wrote:
> > Quoting Kumar Valsan, Prathap (2019-10-19 00:24:13)
> > > On Fri, Oct 18, 2019 at 11:14:39PM +0100, Chris Wilson wrote:
> > > > +static int check_l3cc_table(struct intel_engine_cs *engine,
> > > > + const struct drm_i915_mocs_table *table,
> > > > + const u32 *vaddr, int *offset)
> > > > +{
> > > > + u16 unused_value = table->table[I915_MOCS_PTE].l3cc_value;
> > > > + unsigned int i;
> > > > + u32 expect;
> > > > +
> > > > + if (1) { /* XXX skip MCR read back */
> > > > + *offset += table->n_entries / 2;
> > > > + return 0;
> > > > + }
> > >
> > > I think l3cc reset test is valid only from Gen12+. Before that since its
> > > loaded from the golden context, table stays the same between reset.
> >
> > That doesn't affect the validity of actually checking that the values
> > don't change. The problem as I understand it is that they lie inside the
> > magic 0xb00 region that is broadcast across the slices and not
> > accessible from CS, see engine_wa_list_verify() and mcr_range. Sadly
> > using the GPU is the cleanest way to emulate userspace interaction with
> > the *GPU*.
> > -Chris
> Hmmm.. But from igt test we are submiting a secure BB to read the L3
> MOCS. Not quite clear how that works then.
The simple answer is I see precisely the same fail in gem_mocs_settings
:)
The real question is why CI does not.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
