Message-ID: <20120418142438.GA20469@phenom.ffwll.local>
Date:	Wed, 18 Apr 2012 16:24:38 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>,
	linaro-mm-sig@...ts.linaro.org,
	LKML <linux-kernel@...r.kernel.org>,
	DRI Development <dri-devel@...ts.freedesktop.org>,
	linux-media@...r.kernel.org, Rob Clark <rob.clark@...aro.org>,
	Rebecca Schultz Zavin <rebecca@...roid.com>
Subject: Re: [PATCH] dma-buf: mmap support

On Wed, Apr 18, 2012 at 02:06:13PM +0000, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
> > +   Because existing importing subsystems might presume coherent mappings for
> > +   userspace, the exporter needs to set up a coherent mapping. If that's not
> > +   possible, it needs to fake coherency by manually shooting down ptes when
> > +   leaving the cpu domain and flushing caches at fault time. Note that all the
> > +   dma_buf files share the same anon inode, hence the exporter needs to replace
> > +   the dma_buf file stored in vma->vm_file with it's own if pte shootdown is
> > +   requred. This is because the kernel uses the underlying inode's address_space
> > +   for vma tracking (and hence pte tracking at shootdown time with
> > +   unmap_mapping_range).
> > +
> > +   If the above shootdown dance turns out to be too expensive in certain
> > +   scenarios, we can extend dma-buf with a more explicit cache tracking scheme
> > +   for userspace mappings. But the current assumption is that using mmap is
> > +   always a slower path, so some inefficiencies should be acceptable.
> > +
> > +   Exporters that shoot down mappings (for any reasons) shall not do any
> > +   synchronization at fault time with outstanding device operations.
> > +   Synchronization is an orthogonal issue to sharing the backing storage of a
> > +   buffer and hence should not be handled by dma-buf itself. This is explictly
> > +   mentioned here because many people seem to want something like this, but if
> > +   different exporters handle this differently, buffer sharing can fail in
> > +   interesting ways depending upong the exporter (if userspace starts depending
> > +   upon this implicit synchronization).
> 
> How do you ensure that no device can do DMA on the buffer while it's mapped
> into user space in a noncoherent manner?

We don't. Letting userspace shoot into it's foot is part of the interface.
drm drivers and afaik also v4l has some explicit interfaces where
userspace and the kernel can communicate who is allowed to stomp on a
buffer (and sync up access with various degrees of sophistication).
Userspace still needs to use this interfaces to ensure that any dma
activity it wants to have completed is completed.

To ensure coherency for userspace that does not try to get unnecessary
holes in its feet, the exporter needs to zap all ptes pointing to a dma
buf object and flush relevant parts of the cpu cache before device dma
starts (signalled with dma_buf_map_sg from the importer atm, but we'll
eventually grow streaming support I guess). On page fault time it has then
to invalidate any cpu caches, so that userspace does not read stale data.

Like I've said in the above blurb in the documentation, I think
synchronization is an orthogonal issue to sharing memory.
-Daniel
-- 
Daniel Vetter
Mail: daniel@...ll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists