[igt-dev] [PATCH] selftests/i915_gem_gtt: Create igt_ggtt_scratch subtest

[Chris Wilson]

Quoting Ewelina Musial (2018-04-11 11:57:39)
> On Wed, Apr 11, 2018 at 11:43:34AM +0100, Chris Wilson wrote:
> > Quoting Ewelina Musial (2018-04-11 11:20:56)
> > > On Wed, Apr 11, 2018 at 09:48:21AM +0100, Chris Wilson wrote:
> > > > Quoting Ewelina Musial (2018-04-11 09:27:12)
> > > > > Test have similar functionality that gem_cs_prefetch IGT test
> > > > > but gem_cs_prefetch is not up to date and there was an idea
> > > > > to move this test to kselftests so this is respond for this
> > > > > request.
> > > > 
> > > > gem_cs_prefetch itself does one thing: verify that we cannot cross the
> > > > page boundary beyond the last page of the GTT. It is about the Command
> > > > Streamer prefetch; there is no command streamer here.
> > > > 
> > > > gem_cs_prefetch could be simplified by EXEC_OBJECT_PINNED, I think the
> > > > notes got muddled up.
> > > > -Chris
> > > 
> > > Probably you are right. I focused on some other point of view. My test is checking
> > > that if we cross the boundary beyond the last page values are stored in scratch.
> > 
> > If we cross the boundary beyond the end of the last page of the GTT, there are no
> > more pages. Hitting scratch is not a sensible test; scratch is just a
> > figment of the imagination, the only reason it may exist in some
> > circumstances is to prevent page faults. And other than vtd w/a that
> > was a bad idea.
> > -Chris
> 
> So do you think that scenario give us something or I should focus on some other scenario?
> I am just wondering, even if scratch is some imagination we need to be sure that after
> removing page this address will point to scratch not to some random value, right?

No. On many machines, we don't set <the empty space> to point to anything,
we don't even write no-page into GSM block as that takes a few ms during
module load. So trying to have a universal rule about what the implementation
should do, doesn't make sense. Design wise scratch is scratch, it is not
meant to be retrievable.

From the standpoint of the question you asked, the answer is just that
have to make sure that insert_page(s) end up with pages where we say
they are; clear_range on the other hand has to be regarded as a no-op in
the general case.

Then you look at the uABI boundary and everytime you ask a question
about how do we define the expected user behaviour in such a case, it is
often much easier to actually test the uABI boundary itself. (At least
emulating userspace from inside the kernel looks fraught, though the
kernel ELF modules might be very useful to do just that.)
-Chris