[Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

[Yu Dai]

On 11/11/2015 01:07 AM, Chris Wilson wrote:
> On Tue, Nov 10, 2015 at 03:27:36PM -0800, yu.dai at intel.com wrote:
> > From: Alex Dai <yu.dai at intel.com>
> >
> > We keep a copy of GuC fw in a GEM obj. However its content is lost
> > if the GEM obj is swapped (igt/gem_evict_*). Therefore, the later
> > fw loading during GPU reset will fail. Mark the obj dirty after
> > copying data into the pages. So its content will be kept during
> > swapped out.
> >
> > Signed-off-by: Alex Dai <yu.dai at intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index f1e3fde..3b15167 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -5199,6 +5199,7 @@ i915_gem_object_create_from_data(struct drm_device *dev,
> >  	i915_gem_object_pin_pages(obj);
> >  	sg = obj->pages;
> >  	bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
> > +	obj->dirty = 1;
>
> That's one way of doing it, but atypical for our CPU access to the pages.
> The root cause is still that sg_copy_from_buffer() isn't calling
> set_page_dirty() and so there will be other places in the kernel that
> fall foul of it. Also, not that we could have written this to not require
> the whole object to be pinned at once as well.
>
> I would prefer this to be fixed in sg_copy_from_buffer() for the reason
> that all callers are susceptible to this bug.
> -Chris
>
Makes sense. I will keep this as it for now. We want to set this GEM obj 
dirty too in addition of marking each page dirty. A change in 
sg_copy_buffer will have big impact on kernel though.

Thanks,
Alex