On Mon, Dec 07, 2015 at 01:43:28PM +0000, Tvrtko Ursulin wrote: > On 11/11/15 10:36, ankitprasad.r.sharma@xxxxxxxxx wrote: > >From: Ankitprasad Sharma <ankitprasad.r.sharma@xxxxxxxxx> > > > >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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
