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
| ||
|
Date: Tue, 23 Oct 2018 19:51:30 +0000 From: Loic PALLARDY <loic.pallardy@...com> To: Suman Anna <s-anna@...com>, "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>, "ohad@...ery.com" <ohad@...ery.com> CC: "linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Arnaud POULIQUEN" <arnaud.pouliquen@...com>, "benjamin.gaignard@...aro.org" <benjamin.gaignard@...aro.org> Subject: RE: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function Hi Suman, > -----Original Message----- > From: Suman Anna <s-anna@...com> > Sent: mardi 23 octobre 2018 18:51 > To: Loic PALLARDY <loic.pallardy@...com>; bjorn.andersson@...aro.org; > ohad@...ery.com > Cc: linux-remoteproc@...r.kernel.org; linux-kernel@...r.kernel.org; > Arnaud POULIQUEN <arnaud.pouliquen@...com>; > benjamin.gaignard@...aro.org > Subject: Re: [PATCH v4 02/17] remoteproc: add rproc_va_to_pa function > > Hi Loic, Bjorn, > > On 7/27/18 8:14 AM, Loic Pallardy wrote: > > This new function translates CPU virtual address in > > CPU physical one according to virtual address location. > > > > Signed-off-by: Loic Pallardy <loic.pallardy@...com> > > Acked-by: Bjorn Andersson <bjorn.andersson@...aro.org> > > --- > > drivers/remoteproc/remoteproc_core.c | 18 +++++++++++++++++- > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/remoteproc/remoteproc_core.c > b/drivers/remoteproc/remoteproc_core.c > > index 437fabf..8e5fe1e 100644 > > --- a/drivers/remoteproc/remoteproc_core.c > > +++ b/drivers/remoteproc/remoteproc_core.c > > @@ -140,6 +140,22 @@ static void rproc_disable_iommu(struct rproc > *rproc) > > iommu_domain_free(domain); > > } > > > > +static phys_addr_t rproc_va_to_pa(void *cpu_addr) > > +{ > > + /* > > + * Return physical address according to virtual address location > > + * - in vmalloc: if region ioremapped or defined as > dma_alloc_coherent > > + * - in kernel: if region allocated in generic dma memory pool > > + */ > > + if (is_vmalloc_addr(cpu_addr)) { > > + return page_to_phys(vmalloc_to_page(cpu_addr)) + > > + offset_in_page(cpu_addr); > > + } > > + > > + WARN_ON(!virt_addr_valid(cpu_addr)); > > + return virt_to_phys(cpu_addr); > > +} > > + > > /** > > * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc > address > > * @rproc: handle of a remote processor > > @@ -711,7 +727,7 @@ static int rproc_handle_carveout(struct rproc > *rproc, > > * In this case, the device address and the physical address > > * are the same. > > */ > > - rsc->pa = dma; > > + rsc->pa = (u32)rproc_va_to_pa(va); > > While I agree with the direction here, we ought to add a check here > warning users if some address bits are getting lost as a result of the > typecast. Granted the issue may have been present previously with > dma_addr_t as well, but most platforms were using 32-bit dma addresses, > so this was kinda masked. There are ARMv7 platforms with LPAE enabled > allowing physical addresses > 32-bits. > > In anycase, we definitely have a need for a v2 for the fw_rsc_carveout > structure to deal with 64-bit addresses. > Agree with you. Assumption for this series was to keep resource table as it is. Resource table improvement is planned in a second step. Regards, Loic > regards > Suman > > > > > carveout->va = va; > > carveout->len = rsc->len; > >
Powered by blists - more mailing lists