On Tue, Nov 08, 2011 at 08:22:48AM +0100, Thomas Hellstrom wrote: > On 11/08/2011 12:40 AM, j.glisse@xxxxxxxxx wrote: > >From: Jerome Glisse<jglisse@xxxxxxxxxx> > > > >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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
