RE: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain

[Peng Fan]

> -----Original Message-----
> From: hch@xxxxxxxxxxxxx [mailto:hch@xxxxxxxxxxxxx]
> Sent: 2019年1月28日 16:00
> To: Peng Fan <peng.fan@xxxxxxx>
> Cc: hch@xxxxxxxxxxxxx; Stefano Stabellini <sstabellini@xxxxxxxxxx>;
> mst@xxxxxxxxxx; jasowang@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> linux-remoteproc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx; luto@xxxxxxxxxx; jgross@xxxxxxxx;
> boris.ostrovsky@xxxxxxxxxx; Andy Duan <fugang.duan@xxxxxxx>
> Subject: Re: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain
> 
> On Fri, Jan 25, 2019 at 09:45:26AM +0000, Peng Fan wrote:
> > Just have a question,
> >
> > Since vmalloc_to_page is ok for cma area, no need to take cma and per
> > device cma into consideration right?
> 
> The CMA area itself it a physical memory region.  If it is a non-highmem
> region you can call virt_to_page on the virtual addresses for it.  If it is in
> highmem it doesn't even have a kernel virtual address by default.
> 
> > we only need to implement a piece code to handle per device specific
> > region using RESERVEDMEM_OF_DECLARE, just like:
> > RESERVEDMEM_OF_DECLARE(rpmsg-dma, "rpmsg-dma-pool",
> > rmem_rpmsg_dma_setup); And implement the device_init call back and
> > build a map between page and phys.
> > Then in rpmsg driver, scatter list could use page structure, no need
> > vmalloc_to_page for per device dma.
> >
> > Is this the right way?
> 
> I think this should work fine.  If you have the cycles for it I'd actually love to
> be able to have generic CMA DT glue for non DMA API driver allocations, as
> there obviously is a need for it.  So basically the same as above, just added
> to kernel/cma.c as a generic API.

Thanks for the hints. I'll try to add that.

Thanks,
Peng.