[Intel-gfx] [PATCH 02/22] drm/i915/gem: Pull phys pread/pwrite implementations to the backend

[Chris Wilson]

Quoting Matthew Auld (2020-11-05 16:02:38)
> On Thu, 5 Nov 2020 at 15:45, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> >
> > Quoting Matthew Auld (2020-11-05 15:40:20)
> > > On Thu, 5 Nov 2020 at 15:39, Matthew Auld
> > > <matthew.william.auld at gmail.com> wrote:
> > > >
> > > > On Thu, 5 Nov 2020 at 10:11, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > > >
> > > > > More the specialised interation with the physical GEM object from the
> > > >
> > > > Move                           interaction
> > > >
> > > > > pread/pwrite ioctl handler into the phys backend.
> > > > >
> > > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Reviewed-by: Matthew Auld <matthew.auld at intel.com>
> > >
> > > Does  this need  Fixes btw?
> >
> > I was thinking so long as we land before dg1 it would be fine. If we did
> > a fake lmem with no aperture, we would have problems already. But there's
> > no user exposure, so no pressing need for cc:stable.
> 
> I was thinking we could maybe be evil and achieve the same thing with
> existing userspace, just requires the use of gtt_mmap to steal all of
> the mappable aperture at the opportune time, such that
> insert_mappable_node() still returns -ENOSPC? Or maybe I am
> misunderstanding something.

To steal all the aperture... Harder than you might think...

Everything with full-ppgtt is pretty much impossible to arbitrarily pin
the aperture. Many, many, many contexts would do. But we have to be sure
not to leave any holes. The contexts can be anywhere, so we are
looking at about 60k contexts before we start exhausting the GGTT, and
there's no guarantee we didn't leave a hole large enough for the 4K GGTT
slot.

On global/aliasing, we can pin framebuffers into the aperture, but only
two for each CRTC. Again, we have to leave no holes. That seems difficult
with so few objects we can pin.

The other angle is to try and prolong all the transient pins, but they
are meant to be tiny ones... Wait. We can arbitrarily delay
copy_from_user by using userfaultfd, so we would only need 64k threads
or so to force ourselves into ENOSPC. That seems doable...
-Chris