Re: [PATCH 00/34] PPGTT prep part 2 (and unmerged part 1)

[Ben Widawsky <ben@bwidawsk.net>]

On Sat, May 25, 2013 at 12:26:34PM -0700, Ben Widawsky wrote:
> Hello.
> 
> I'm continuing to develop full PPGTT support for the i915 driver. This
> series is a follow-up to the previously posted RFC [1]. This series
> contains reworked versions of the unmerged patches (fingers crossed that
> I didn't miss review comments). I've rebased this series to hell and
> back, so I'm sure there are some lingering errors due to that. I've found
> several, but my eyes are no longer capable of finding them. I've also added
> some last minute fixups, which I always promise myself I'll never do because
> they always have bugs.
> 
> To reiterate the steps I am planning to take which I did this in the
> previous RFC [1], but it has changed a bit:
> 
> 1. Make a link between contexts and PPGTT. Every context has  it's own
>    address space implemented.
> 2. Create the VMA/VM, plumb through the driver.
> 3. Create a context per fd. This involves abstracting the notion of
>    context to not just mean a HW context, but also an address space.
> 4. Switch address spaces on context switch.
> 5. Develop interfaces.
> 
> This patch series addresses steps 1 & 2. A lot of the future patches
> should have much less room for debate on what color to paint the
> bikeshed, so I feel this is a good point to submit for some review. I am
> currently developing 3 & 4. I have some half baked patches which aren't
> really ready, but do give me some notion that things will work.  Note
> that The order of 3 and 4 really matter because if we start switching
> page tables for applications not using contexts, everything will blow up
> pretty badly.
> 
> To not scare off potential reviewers, even though the series is as long
> as it is, many of the patches really could be squashed. To keep rebase +
> easier review, I've split things out to multiple steps.
> 
> 1-5: Random fixes.
> 6-15: Equivalent to reworked version of the PPGTT prep part 1
>   6-9: Make PPGTT PDE allocation more generic
>   10-15: Tie contexts to PPGTT.
> 
> 16-34: create the VM and VMAs.
>   16-20: Mostly cut and paste to set us up for future patches.
>   21-25: Set up the address space abstraction.
>   26-31: Reorganize code to prepare for VMAs
>   31-34: are logically one patch. I split them out for my own debug
> 	after the enormous patch didn't work. I'm fine with squashing
> 	them in to 1 after review, or leaving a large bisect warning
> 	(as I've done).
> 
> I do have a work in progress branch on fd.o [2]. This may not reflect this
> series 1:1 as it will have rebases, plus some future patches as I feel they are
> ready. If someone wants a branch on fd.o for review, please let me know.
> 
> References:
> [1] http://lists.freedesktop.org/archives/intel-gfx/2013-April/027144.html
> [2] http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=ppgtt-prep-2

I've forced pushed the following to my repo linked above:

Rebased on the latest -nightly as the time.

Added a patch to disable ppgtt when on gen6 + vtd. This would have broken in
the old series. The patch is a bit tricky in that it will make the code paths
identical for PPGTT and non-PPGTT on GEN6, however it won't write the PPGTT
enable bits when vt-d is enabled. This patch is untested...

Kill guard page first, then move PDEs to a BO. Originally the patches were
submitted in the reverse order. Since we already have the PDEs above the guard
page, the guard page is immediately killable.

Rename gtt_list to global_list. This just clears confusion, and has already
been merged by Daniel.

Pin and unpin pages at bind/unbind. This will help keep put_pages clean. This
too has already been merged by Daniel.

> 
-- 
Ben Widawsky, Intel Open Source Technology Center