dma-buf non-coherent mmap

[Thomas Hellstrom]

On 10/31/2013 10:10 PM, Rob Clark wrote:
> On Thu, Oct 31, 2013 at 4:40 PM, Thomas Hellstrom <thellstrom at vmware.com> wrote:
>> On 10/31/2013 06:52 PM, Rob Clark wrote:
>>> On Thu, Oct 31, 2013 at 1:00 PM, Thomas Hellstrom <thellstrom at vmware.com>
>>> wrote:
>>>> Hi!
>>>>
>>>> I'm just looking over what's needed to implement drm Prime / dma-buf
>>>> exports
>>>> + imports in the vmwgfx driver. It seems like most dma-bufs ops are quite
>>>> straightforward to implement except user-space mmap().
>>>>
>>>> The reason being that vmwgfx dma-bufs will be using completely
>>>> non-coherent
>>>> memory, whenever there needs to be CPU accesses.
>>>>
>>>> The accelerated contents resides in an opaque structure on the device
>>>> into
>>>> which we can DMA to and from, so for mmap to work we need to zap ptes and
>>>> DMA to the device when doing something accelerated, and on the first
>>>> page-fault DMA data back and wait for idle if the device did a write to
>>>> the
>>>> dma-buf.
>>>>
>>>> Now this shouldn't really be a problem if dma-bufs were only used for
>>>> cross-device sharing, but since people apparently want to use dma-buf
>>>> file
>>>> handles to share CPU data between processes it really becomes a serious
>>>> problem.
>>>>
>>>> Needless to say we'd want to limit the size of the DMAs, and have mmap
>>>> users
>>>> request regions for read, and mark regions dirty for write, something
>>>> similar to gallium's texture transfer objects.
>>>>
>>>> Any ideas?
>>> well, I think vmwgfx is part of the reason we decided mmap would be
>>> optional for dmabuf.  So perhaps it is an option to simply ignore
>>> mmap?
>>>
>>> BR,
>>> -R
>>
>> Well, I'd be happy to avoid mmap, but then what does optional mean in this
>> context?
>> That all generic user-space apps *must* implement a workaround if mmap isn't
>> implemented?
> well, mmap was mostly just added because it was needed by android for
> ION on dmabuf.
>
> I think it is an option to just not use dmabuf mmap in a linux
> userspace.  I mean, we could also define some ioctls to give us pwrite
> and other similar sort of functionality if it is needed.

I think that if direct user-space cpu-access to dma-buf is ever needed 
by linux,
something like that is a better option. Best IMHO would be to avoid 
user-space
cpu-access completely.

Regards,
/Thomas


>
> BR,
> -R
>