From: Christoph Hellwig <hch@lst.de>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Christoph Hellwig <hch@lst.de>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
steve.kang@unisoc.com
Subject: Re: [PATCH] kernel: dma: let dma use vmalloc area
Date: Mon, 27 Nov 2023 10:32:10 +0100 [thread overview]
Message-ID: <20231127093210.GA3662@lst.de> (raw)
In-Reply-To: <CAGWkznFf5hdFRomLXDzoxEKVgiKY--DFbHjRLAMvgvodA01EFw@mail.gmail.com>
On Mon, Nov 27, 2023 at 04:56:45PM +0800, Zhaoyang Huang wrote:
> Sorry for the confusion, please find below codes for more information.
> dma_init_coherent_memory
> memremap
> addr = ioremap_wt(offset, size);
> What I mean is addr is a vmalloc address, which is implicitly mapped
> by dma's framework and not be aware of to the driver.
Yes. And it is only returned from dma_alloc_coherent, which should
never be passed to dma_map_<anything>.
> Please correct me if I am wrong. According to my understanding, cache
> consistency could be solved inside dma_map_page via either
> dma_direct_map_page(swio/arch_sync_dma_for_device) or ops->map_page.
> The original thought of rejecting vmalloc is that this pa is not safe
> as this mapping could go in any time. What I am suggesting is to let
> this kind of va be enrolled.
But that only works for the direct mapping. It does not work for the
additional aliases created by vmap/ioremap/memremap. Now that only
matters if the cache is virtually indexed, which is rather unusual
these days.
next prev parent reply other threads:[~2023-11-27 9:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 3:09 [PATCH] kernel: dma: let dma use vmalloc area zhaoyang.huang
2023-11-27 3:29 ` Zhaoyang Huang
2023-11-27 7:14 ` Christoph Hellwig
2023-11-27 8:56 ` Zhaoyang Huang
2023-11-27 9:32 ` Christoph Hellwig [this message]
2023-11-27 11:24 ` Robin Murphy
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=20231127093210.GA3662@lst.de \
--to=hch@lst.de \
--cc=huangzhaoyang@gmail.com \
--cc=iommu@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=robin.murphy@arm.com \
--cc=steve.kang@unisoc.com \
--cc=zhaoyang.huang@unisoc.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.