[Intel-gfx] [PATCH] drm/i915: Migrate stolen objects before hibernation

[Chris Wilson]

On Tue, Jun 30, 2015 at 02:07:41PM +0200, Daniel Vetter wrote:
> On Tue, Jun 30, 2015 at 12:25:54PM +0100, Chris Wilson wrote:
> > On Tue, Jun 30, 2015 at 12:54:02PM +0200, Daniel Vetter wrote:
> > > The gpu should be able so pinned for scanout is the only corner case I can
> > > think of atm.
> > 
> > Hmm. That's a nuisance. But... We can throw away all the VM bindings
> > that are unpinned, and then rewrite those that are left with the shmemfs
> > pages.
> > 
> > It's ugly. On migration back we would have to do a similar trick, and we
> > need to tell a few white lies to get past some of our internal BUG_ON.
> > However, as the contents are the same and the PTE writes are atomic into
> > the GGTT, it should be invisible to the user.
> > 
> > For internally allocated frontbuffers, I was expecting to mark them as
> > volatile and let them lose their contents across hibernation - because
> > they will be immediately cleared afterwards (at least so I expect).
> 
> New upcoming complications: On some still super-secret upcoming platform
> we need special ggtt vmas for scanout, to pin the backing storage into
> suitable memory. And because the hw implementation does replace the ggtt
> pte with the physical page entry (i.e. resolving dmar and stuff) it
> disallows any writes to the ptes. So we can't replace the ggtt ptes while
> the vma is pinned at all.

In that scheme, our backing storage is incoherent with the actual
contents. So we don't need the backing storage at all after setting the
PTE and the entire object is volatile (so not saved across hibernate
anyway). We wouldn't want to reserve stolen space for that, just a
custom allocator and discard the pages asap. (Or we have a phys object
scheme that does a lot of copying...)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre