Hi

Am 18.05.20 um 16:40 schrieb Daniel Vetter:
> On Mon, May 18, 2020 at 12:11:32PM +0200, Gerd Hoffmann wrote:
>> On Mon, May 18, 2020 at 10:50:15AM +0200, Thomas Zimmermann wrote:
>>> Hi Gerd
>>>
>>> Am 18.05.20 um 10:23 schrieb Gerd Hoffmann:
>>>>>> $ git grep drm_gem_shmem_mmap
>>>>>>
>>>>>> We also need correct access from userspace, otherwise the gpu is going to
>>>>>> be sad.
>>>>>
>>>>> I've been thinking about this, and I think it means that we can never
>>>>> have cached mappings anywhere. Even if shmem supports it internally for
>>>>> most drivers, as soon as the page are exported, the importer could
>>>>> expect uncached memory.
>>>>
>>>> The importer should not expect anything but call dma-buf ops so the
>>>> exporter has a chance to handle this correctly.
>>>
>>> I have the following case in mind: Suppose the exporter maps cached
>>> pages and the importer expects uncached pages for DMA. There is
>>> map_dma_buf/unmap_dma_buf, which can implement a cache flush for the
>>> cached pages. Is it guaranteed that the importer calls this around each
>>> DMA operation?
>>
>> I think the importer is supposed to do that, but I wouldn't surprised if
>> there are cases in tree where this isn't implemented correctly ...
> 
> Yup, this is very much a case of "supposed to" but "in practice, many
> actually dont". The reason is that setting up mappings is expensive, so
> best avoid.

Thanks to both of you for answering the question.

> 
> We filled that gap a few years after dma-buf landed with the
> begin/end_cpu_access hooks, which allow the exporter to do cache flushing
> (using something like dma_sync_sg_for_device/cpu) and for this to all work
> properly. We even added ioctl so that the mmap on the dma-buf works
> correctly.
> 
> But most importers still ignore this, so it's all fail :-/ But in theory
> the pieces to make cached mappings work over dma-buf, even for importers
> that need uncached, are all there.
> 
> Cheers, Daniel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer