From: Christoph Hellwig <hch@infradead.org>
To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
Cc: "Christoph Hellwig" <hch@infradead.org>,
"Christian König" <christian.koenig@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: dma coherent memory user-space maps
Date: Thu, 31 Oct 2019 14:54:15 -0700 [thread overview]
Message-ID: <20191031215415.GA9809@infradead.org> (raw)
In-Reply-To: <b811f66d-2353-23c6-c9fa-e279cdb0f832@shipmail.org>
Hi Thomas,
sorry for the delay. I've been travelling way to much laterly and had
a hard time keeping up.
On Tue, Oct 08, 2019 at 02:34:17PM +0200, Thomas Hellström (VMware) wrote:
> /* Obtain struct dma_pfn pointers from a dma coherent allocation */
> int dma_get_dpfns(struct device *dev, void *cpu_addr, dma_addr_t dma_addr,
> pgoff_t offset, pgoff_t num, dma_pfn_t dpfns[]);
>
> I figure, for most if not all architectures we could use an ordinary pfn as
> dma_pfn_t, but the dma layer would still have control over how those pfns
> are obtained and how they are used in the kernel's mapping APIs.
>
> If so, I could start looking at this, time permitting, for the cases where
> the pfn can be obtained from the kernel address or from
> arch_dma_coherent_to_pfn(), and also the needed work to have a tailored
> vmap_pfn().
I'm not sure that infrastructure is all that helpful unfortunately, even
if it ended up working. The problem with the 'coherent' DMA mappings
is that we they have a few different backends. For architectures that
are DMA coherent everything is easy and we use the normal page
allocator, and your above is trivially doable as wrappers around the
existing functionality. Other remap ptes to be uncached, either
in-place or using vmap, and the remaining ones use weird special
allocators for which almost everything we can mormally do in the VM
will fail.
I promised Christian an uncached DMA allocator a while ago, and still
haven't finished that either unfortunately. But based on looking at
the x86 pageattr code I'm now firmly down the road of using the
set_memory_* helpers that change the pte attributes in place, as
everything else can't actually work on x86 which doesn't allow
aliasing of PTEs with different caching attributes. The arm64 folks
also would prefer in-place remapping even if they don't support it
yet, and that is something the i915 code already does in a somewhat
hacky way, and something the msm drm driver wants. So I decided to
come up with an API that gives back 'coherent' pages on the
architectures that support it and otherwise just fail.
Do you care about architectures other than x86 and arm64? If not I'll
hopefully have something for you soon.
next prev parent reply other threads:[~2019-10-31 21:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 12:34 Thomas Hellström (VMware)
2019-10-21 12:26 ` Thomas Hellström (VMware)
2019-10-23 4:04 ` Christoph Hellwig
2019-10-31 21:54 ` Christoph Hellwig [this message]
2019-11-04 6:38 ` Thomas Hellström (VMware)
2019-11-04 6:58 ` Thomas Hellström (VMware)
2019-11-04 11:29 ` Koenig, Christian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191031215415.GA9809@infradead.org \
--to=hch@infradead.org \
--cc=christian.koenig@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas_os@shipmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome