On Fri, 2014-04-11 at 08:55 +0000, Daniel Vetter wrote: > On Thu, Apr 10, 2014 at 10:12:39AM +0000, Gupta, Sourab wrote: > > On Wed, 2014-04-09 at 13:06 +0000, Daniel Vetter wrote: > > > On Tue, Apr 08, 2014 at 06:53:03AM +0000, Gupta, Sourab wrote: > > > > On Tue, 2014-04-08 at 06:45 +0000, Chris Wilson wrote: > > > > > On Tue, Apr 08, 2014 at 04:32:02AM +0000, Gupta, Sourab wrote: > > > > > > Hi Rodrigo, > > > > > > In this patch, while freeing the purgeable stolen object, the memory > > > > > > node also has to be freed, so as to make space for new object. We need > > > > > > to call drm_mm_remove_node while freeing obj. > > > > > > > > > > > > The below modification patch was floated earlier for this purpose: > > > > > > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041282.html > > > > > > > > > > Right, I have a v2 locally with the fix you identified. > > > > > -Chris > > > > > > > > > Ok, Thanks Chris. > > > > > > I'd really prefer if someone would pick up all the > > > stolen/create2_ioctl/whatever patches, pack them up into a polished > > > series, add the testcases and submit this all for review and merging. > > > > > > Otherwise this will linger forever and we'll get nowhere. Chris seems > > > swamped with other stuff, so Sourab could you please take a look at this? > > > > > > Please check with your manager that you have sufficient bandwidth to pull > > > this through. > > > > > > > I'll be on vacation from next week, so I'll be able to gauge this better > > after coming back. > > Nevertheless, I have some questions regarding the expectation of > > userspace code changes required for these patches (i.e. libdrm changes > > and igt testcases) > > > > 1) For libdrm , I am assuming, a counterpart of > > drm_intel_gem_bo_alloc_tiled() function would call the create2 ioctl and > > take in the parameters needed. > > Should the caching of objects from libdrm need to take care of both the > > placement domains seperately (as in different sets of bo buckets)? > > Should libdrm be transparent to all the combinations of different > > parameters being passed by user or should the prohibited combinations be > > disallowed from libdrm side? > > I'm not sure whether we need a cache implemented in libdrm. Since stolen > objects are fairly special it's probably easier to just have a simple > linear cache tailor-made in the respective UMD. So just exposing > create2_ioctl should be good enough. > > > 2) For the igt, since we have a lot of parameters exposed to user, the > > number of subtests required may be huge and still they may not test out > > everything. > > So, Is the expectation here to have exhaustive test cases for all the > > parameters (tiling/cache/domain/madvise/offset etc.) going in as input > > to the create2 ioctl? > > For eg. let us say we are going to check the render copy operation of > > src and dest bo's. Do we need to provide all possible combinations of > > different (create2 ioctl) input parameters to these src and dest bo's > > and then run the render copy test for all these combinations. > > Any guiding pointers from your side as to how we may go about the igt > > testcases? > > At a high-level there's two parts for igt tests: > - First is functional tests, where we try to make sure that the feature > actually works. I.e. allocate some stolen memory and then do something > with it, making sure that data access for the gpu and similar things > work. For this we just want some reasonable base coverage so that when > we hit a bug somewhere it's easy to extend the testcase to cover that > bug with a specific subtest. > > - Then there's interface testing. kernel/userspace is a trust barrier, so > we need to make sure that evil userspace can't make the kernel crash > with some crazy invalid combination of flags or operations (like create > a stolen object and then try to mmap it). Since this is security > relevant and also since we can't ever change established userspace ABI I > want full coverage of all cases. But this is just about detecting abuse > correctly, no functional tests here. > > For details see my two blog posts on the topic: > > http://blog.ffwll.ch/2013/11/botching-up-ioctls.html > > http://blog.ffwll.ch/2013/11/testing-requirements-for-drmi915.html > > Cheers, Daniel Thanks Daniel, We'll take care of the above points for libdrm changes and igt. Regards, Sourab _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
