[PATCH 01/12] drm/ttm: remove userspace backed ttm object support

[Jerome Glisse]

On Tue, Nov 08, 2011 at 08:22:48AM +0100, Thomas Hellstrom wrote:
> On 11/08/2011 12:40 AM, j.glisse at gmail.com wrote:
> >From: Jerome Glisse<jglisse at redhat.com>
> >
> >This was never use in none of the driver, properly using userspace
> >page for bo would need more code (vma interaction mostly). Removing
> >this dead code in preparation of ttm_tt&  backend merge.
> >
> 
> Jerome,
> I actually have using user-space TTMs in the pipe for vmwgfx, and it
> doesn't need more code
> (it was used by the psb driver). There are extra requirements,
> though: It only supports cached memory and user-space CPU-access
> needs to be done using existing VMAs.
> 
> Anyway, I'll try to figure out a way to do this in the context of
> the unified tt / tt_backends.
> 

Issue, and i might be wrong here, is that you need to mark the user
vma as reserved and you need to split the vma to covert only the
portion you want. linux kernel a no helper for that. omap people
use mlock on the range they want to use to make sure that page
associated to the vma are lock and that the vma is split to only
cover the range. I don't think it's safe/enough as userspace can
unlock the vma in our back and things might fall apart at that
point.

My idea was to use mlock to split the vma and then set the reserved
flags on the vma. This will forbid userspace to munlock. When memory
is no longer needed you have to go back to locked flag and then
munlock. Also we might want to do things with page of the vma, for
instance if the object move to vram we might want to free those
pages, but here i fear i need to take a closer look at linux mm
to see what we can do safely on those page to not break any of
the kernel assumptions on those pages.

Anyway, from my inspection this whole things is fragile in regards
of other mm activities that might happen.

Cheers,
Jerome