[Intel-gfx] [PATCH 2/6] drm/i915: Support for creating Stolen memory backed objects

Daniel Vetter daniel at ffwll.ch
Thu Dec 10 00:40:40 PST 2015

On Mon, Dec 07, 2015 at 01:43:28PM +0000, Tvrtko Ursulin wrote:
> On 11/11/15 10:36, ankitprasad.r.sharma at intel.com wrote:
> >From: Ankitprasad Sharma <ankitprasad.r.sharma at intel.com>
> >
> >Extend the drm_i915_gem_create structure to add support for
> >creating Stolen memory backed objects. Added a new flag through
> >which user can specify the preference to allocate the object from
> >stolen memory, which if set, an attempt will be made to allocate
> >the object from stolen memory subject to the availability of
> >free space in the stolen region.
> >
> >v2: Rebased to the latest drm-intel-nightly (Ankit)
> >
> >v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)
> >
> >v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
> >Corrected function arguments ordering (Chris)
> Motivated by some questions raised by Dave I went and looked if there is
> something preventing stolen objects use as batch buffers?
> I could not find it myself, so the question is can we end up in the
> relocate_entry_cpu with a batch buffer allocated from stolen, which would
> then call i915_gem_object_get_page and crash?

I think we can. I guess would be good to take Dave's list of places where
we access the underlying backing storage and make sure the stolen igt has
nasty code trying to hit them all.
Daniel Vetter
Software Engineer, Intel Corporation

More information about the Intel-gfx mailing list