linux-kernel - RE: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <AM0PR04MB448123F7FEBCEBD63DE0AF8088970@AM0PR04MB4481.eurprd04.prod.outlook.com>
Date:   Tue, 29 Jan 2019 09:26:41 +0000
From:   Peng Fan <peng.fan@....com>
To:     "hch@...radead.org" <hch@...radead.org>
CC:     Stefano Stabellini <sstabellini@...nel.org>,
        "mst@...hat.com" <mst@...hat.com>,
        "jasowang@...hat.com" <jasowang@...hat.com>,
        "xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
        "linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "jgross@...e.com" <jgross@...e.com>,
        "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
        Andy Duan <fugang.duan@....com>
Subject: RE: [Xen-devel] [RFC] virtio_ring: check dma_mem for xen_domain



> -----Original Message-----
> From: hch@...radead.org [mailto:hch@...radead.org]
> Sent: 2019年1月28日 16:00
> To: Peng Fan <peng.fan@....com>
> Cc: hch@...radead.org; Stefano Stabellini <sstabellini@...nel.org>;
> mst@...hat.com; jasowang@...hat.com; xen-devel@...ts.xenproject.org;
> linux-remoteproc@...r.kernel.org; linux-kernel@...r.kernel.org;
> virtualization@...ts.linux-foundation.org; luto@...nel.org; jgross@...e.com;
> boris.ostrovsky@...cle.com; Andy Duan <fugang.duan@....com>
> 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.