[Intel-gfx] [igt-dev] [PATCH i-g-t] i915: Add gem_vm_create

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-04-01 09:59:53)
> 
> On 01/04/2019 09:52, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-04-01 09:12:08)
> >>
> >>
> >> On 30/03/2019 10:29, Chris Wilson wrote:
> >>> +     /* Verify the trick with the assumed target works */
> >>> +     write_to_address(i915, ctx[0], obj[0].offset, i915);
> >>> +     gem_read(i915, obj[0].handle, 0, &result, sizeof(result));
> >>> +     igt_assert_eq(result, i915);
> >>> +
> >>> +     /* Now check that we can't write to vm[0] from second fd/vm */
> >>> +     write_to_address(other, ctx[1], obj[0].offset, other);
> >>> +     gem_read(i915, obj[0].handle, 0, &result, sizeof(result));
> >>> +     igt_assert_eq(result, i915);
> >>> +
> >>
> >> Relies on objects being zeroes (check) and neither fd being zero. To be
> >> safe add asserts for the latter?
> > 
> > Just replace i915,other there with 1,2. Objects are verified to be zero
> > in other tests, and it's a core piece of ABI that we don't allow
> > information leaks so easily.
> 
> I know, the "check" in parentheses was supposed to mean a ticked 
> checkbox kind of check. I wasn't clear at all. :(

I thought it might have been the case, but wanted to be sure in case it
was a command. (checked) or (✓)

> So I was just saying 
> to put in a quick assert neither fd is zero. Or if we cannot ever 
> imagine running IGT with closed stdin maybe it doesn't matter.

Not assuming i915 is non-zero is reasonable. We don't care what value we
write there, just so long as it is not overwritten by the second value.
But it is useful to confirm that we could write anything :)

So writing 1 then 2 makes us both happy.
-Chris