Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: dma_mmap_fault discussion
To:     Christoph Hellwig <hch@infradead.org>
Cc:     linux-kernel@vger.kernel.org,
        "pv-drivers@vmware.com" <pv-drivers@vmware.com>,
        Thomas Hellstrom <thellstrom@vmware.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
References: <20190905103541.4161-1-thomas_os@shipmail.org>
 <20190905103541.4161-2-thomas_os@shipmail.org>
 <608bbec6-448e-f9d5-b29a-1984225eb078@intel.com>
 <b84d1dca-4542-a491-e585-a96c9d178466@shipmail.org>
 <20190905152438.GA18286@infradead.org>
 <cbbb0e95-8df1-9ab8-59ad-81bd7f3933fa@shipmail.org>
 <20190906063203.GA25415@infradead.org>
 <fcb71585-7fae-c6a0-81f0-1aa632ea621b@shipmail.org>
 <20190906072037.GA29459@infradead.org>
From:   =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28VMware=29?= 
        <thomas_os@shipmail.org>
Organization: VMware Inc.
Message-ID: <611166e3-bb9a-d42c-fb98-18846dfefb8f@shipmail.org>
Date:   Tue, 10 Sep 2019 10:37:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190906072037.GA29459@infradead.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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