[PATCH 1/2] drm/shmem: Use cached mappings by default

[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.

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch