On Wed, Jan 30, 2019 at 09:00:06AM +0100, Christoph Hellwig wrote: > On Wed, Jan 30, 2019 at 04:18:48AM +0000, Jason Gunthorpe wrote: > > Every attempt to give BAR memory to struct page has run into major > > trouble, IMHO, so I like that this approach avoids that. > > Way less problems than not having struct page for doing anything > non-trivial. If you map the BAR to userspace with remap_pfn_range > and friends the mapping is indeed very simple. But any operation > that expects a page structure, which is at least everything using > get_user_pages won't work. > > So you can't do direct I/O to your remapped BAR, you can't create MRs > on it, etc, etc. We do not want direct I/O, in fact at least for GPU we want to seldomly allow access to object vma, so the less thing can access it the happier we are :) All the GPU userspace driver API (OpenGL, OpenCL, Vulkan, ...) that expose any such mapping with the application are very clear on the limitation which is often worded: the only valid thing is direct CPU access (no syscall can be use with those pointers). So application developer already have low expectation on what is valid and allowed to do. Cheers, Jérôme _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
