linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andy Duan <fugang.duan@nxp.com>
To: Christoph Hellwig <hch@infradead.org>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>,
	"ohad@wizery.com" <ohad@wizery.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	Robin Murphy <robin.murphy@arm.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, 10 Jan 2019 01:45:20 +0000	[thread overview]
Message-ID: <VI1PR0402MB36000BD05AF4B242E13D9D05FF840@VI1PR0402MB3600.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <VI1PR0402MB3600799A06B6BFE5EBF8837FFFB70@VI1PR0402MB3600.eurprd04.prod.outlook.com>

From: Andy Duan Sent: 2018年12月28日 9:48
> From: Christoph Hellwig <hch@infradead.org> Sent: 2018年12月27日
> 20:19
> > On Thu, Dec 27, 2018 at 02:36:53AM +0000, Andy Duan wrote:
> > > 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.
> >
> > In that case you need a OF reserved memory node, like we use for the
> > "shared-dma-pool" coherent or contiguous allocations.  Currently we
> > have those two variants wired up the the DMA allocator, but they can
> > also used directly by drivers.  To be honest I don't really like like
> > drivers getting too intimate with the memory allocator, but I also
> > don't think that providing a little glue code to instanciat a CMA pool
> > for a memory that can be used directly by the driver is much of an
> > issue.  Most of it could be reused from the existing code, just with a slightly
> lower level interfaces.
> >
> > > 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.
> >
> > This sentence doesn't parse for me.
> 
> Virtio supply the APIs that require the scatterlist pages for virtio in/out buf:
> int virtqueue_add_inbuf(struct virtqueue *vq,
>                         struct scatterlist *sg, unsigned int num,
>                         void *data,
>                         gfp_t gfp)
> int virtqueue_add_outbuf(struct virtqueue *vq,
>                          struct scatterlist *sg, unsigned int num,
>                          void *data,
>                          gfp_t gfp)
> 
> 
> >
> > > 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.
> >
> > struct scatterlist doesn't (directly) refer to physical address, it
> > refers to page structures, which encode a kernel virtual address in
> > the kernel direct mapping, and we intentionally do not guarantee a
> > return in the kernel direct mapping for the DMA coherent allocator, as
> > in many cases we have to either allocate from a special pool, from a
> > special address window or remap memory to mark it as uncached.  How
> > that is done is an implenentation detail that is not exposed to drivers and
> may change at any time.
> >
> > > 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",
> >
> > You have to do that anyway.
> 
> I discuss with our team, use page allocator cannot match our requirement.
> i.MX8QM/QXP platforms have partition feature that limit M4 only access fixed
> ddr memory region. Suppose other platforms also have similar limitation for
> secure case.
> 
> So it requires to use OF reserved memory for the "shared-dma-pool" coherent
> or contiguous allocations.
> 
Do you have any other comments for the patch ? 
Current driver break remoteproc on NXP i.MX8 platform , the patch is bugfix the virtio rpmsg bus, we hope the patch enter to next and stable tree if no other comments. 


  reply	other threads:[~2019-01-10  1:45 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
2018-12-27 12:19       ` Christoph Hellwig
2018-12-28  1:48         ` Andy Duan
2019-01-10  1:45           ` Andy Duan [this message]
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=VI1PR0402MB36000BD05AF4B242E13D9D05FF840@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