From: Andy Duan <fugang.duan@nxp.com>
To: Christoph Hellwig <hch@infradead.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux-MM <linux-mm@kvack.org>,
Robin Murphy <robin.murphy@arm.com>,
"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
"ohad@wizery.com" <ohad@wizery.com>,
"linux-remoteproc@vger.kernel.org"
<linux-remoteproc@vger.kernel.org>,
"anup@brainfault.org" <anup@brainfault.org>,
"loic.pallardy@st.com" <loic.pallardy@st.com>,
dl-linux-imx <linux-imx@nxp.com>,
Richard Zhu <hongxing.zhu@nxp.com>,
Jason Liu <jason.hui.liu@nxp.com>, Peng Fan <peng.fan@nxp.com>
Subject: RE: [rpmsg PATCH v2 1/1] rpmsg: virtio_rpmsg_bus: fix unexpected huge vmap mappings
Date: Thu, 27 Dec 2018 02:36:53 +0000 [thread overview]
Message-ID: <VI1PR0402MB3600AC833D6F29ECC34C8D4CFFB60@VI1PR0402MB3600.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20181226145048.GA24307@infradead.org>
From: Christoph Hellwig <hch@infradead.org> Sent: 2018年12月26日 22:51
> On Wed, Dec 26, 2018 at 01:27:25PM +0100, Ard Biesheuvel wrote:
> > If there are legal uses for vmalloc_to_page() even if the region is
> > not mapped down to pages [which appears to be the case here], I'd
> > prefer to fix vmalloc_to_page() instead of adding this hack. Or
> > perhaps we need a sg_xxx helper that translates any virtual address
> > (vmalloc or otherwise) into a scatterlist entry?
>
> What rpmsg does is completely bogus and needs to be fixed ASAP. The
> virtual address returned from dma_alloc_coherent must not be passed to
> virt_to_page or vmalloc_to_page, but only use as a kernel virtual address. It
> might not be backed by pages, or might create aliases that must not be used
> with VIVT caches.
>
> rpmsg needs to either stop trying to extract pages from dma_alloc_coherent,
> or just replace its use of dma_alloc_coherent with the normal page allocator
> and the streaming DMA API.
Rpmsg is used to communicate with remote cpu like M4, the allocated memory is shared by Linux and M4 side.
In general, Linux side reserved the static memory region like per-device DMA pool as coherent memory for the RPMSG receive/transmit buffers.
For the static memory region, normal page allocator cannot match the requirement unless there have protocol to tell M4 the dynamic RPMSG receive/transmit buffers.
To stop to extract pages from dma_alloc_coherent, the rpmsg bus implementation base on virtio that already use the scatterlist mechanism for vring memory. So for virtio driver like RPMSG bus, we have to extract pages from dma_alloc_coherent.
I don't think the patch is one hack, as we already know the physical address for the coherent memory, just want to get pages, the interface "pfn_to_page(PHYS_PFN(x))" is very reasonable to the related pages.
If you stick to use normal page allocator and streaming DMA API in RPMSG, then we have to:
- add new quirk feature for virtio like the same function as "VIRTIO_F_IOMMU_PLATFORM", register the new feature for RPMSG virto driver. Then RPMSG virtio bus driver only need to allocate the continuous pages.
- the static memory region for M4 is not supported.
Any idea ?
Regards,
Andy Duan
next prev parent reply other threads:[~2018-12-27 2:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-26 8:25 Andy Duan
2018-12-26 12:27 ` Ard Biesheuvel
2018-12-26 12:27 ` Ard Biesheuvel
2018-12-26 14:50 ` Christoph Hellwig
2018-12-27 2:36 ` Andy Duan [this message]
2018-12-27 12:19 ` Christoph Hellwig
2018-12-28 1:48 ` Andy Duan
2019-01-10 1:45 ` Andy Duan
2019-01-10 13:06 ` Loic PALLARDY
2019-01-11 1:56 ` Andy Duan
2019-01-10 14:07 ` Christoph Hellwig
2019-01-11 1:28 ` Andy Duan
2019-01-14 9:53 ` Christoph Hellwig
2019-01-16 3:38 ` Andy Duan
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=VI1PR0402MB3600AC833D6F29ECC34C8D4CFFB60@VI1PR0402MB3600.eurprd04.prod.outlook.com \
--to=fugang.duan@nxp.com \
--cc=akpm@linux-foundation.org \
--cc=anup@brainfault.org \
--cc=ard.biesheuvel@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=hch@infradead.org \
--cc=hongxing.zhu@nxp.com \
--cc=jason.hui.liu@nxp.com \
--cc=linux-imx@nxp.com \
--cc=linux-mm@kvack.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=loic.pallardy@st.com \
--cc=ohad@wizery.com \
--cc=peng.fan@nxp.com \
--cc=robin.murphy@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox