Re: dma_mmap_fault discussion

From: Thomas HellstrÃm (VMware)
Date: Tue Sep 10 2019 - 04:37:26 EST


On 9/6/19 9:20 AM, Christoph Hellwig wrote:
On Fri, Sep 06, 2019 at 09:10:08AM +0200, Thomas HellstrÃm (VMware) wrote:
It's definitely possible. I was just wondering whether it was necessary, but
it seems like it.
Yepp.

I've pushed a new version out (even hotter off the press) that doesn't
require the region for dma_mmap_prepare, and also uses PAGE_SIZE units
for the offset / length in dma_mmap_fault, which simplifies a few
things.

Hi, Christoph,

I've been looking into this a bit, and while it's possible to make it work for fault, (and for single page kmaps of course, since we have the kernel virtual address already), I run into problems with vmaps, since we basically need to vmap a set of consecutive coherent allocations obtained from the coherent pool.

Also, at mmap time, we need in theory to call dma_mmap_prepare() and save the page_prot for all attrs we might be using at fault time...

I did some thinking into whether we could perhaps cover all or at least the vast majority of architectures and awkward devices more generally with a page prot and a set of pfns. So I looked at how remap_pfn_range() and io_remap_pfn_range() was implemented across architectures, and it turns out that all archs implementing a special io_remap_pfn_range() (sparc and mips) end up calling remap_pfn_range(), and that should mean that any arch that's currently capable of doing fault() should in principle be capable of using vmf_insert_pfn_prot() with a suitable pfn that in most (if not all) cases should be obtainable from the kernel virtual address.

So do you think a way forward could perhaps be to have a dma_common_get_pfn_sgtable() and add a generic vmap_pfn_prot()?

Thanks,

Thomas