| 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, 29 Mar 2016 13:44:41 +0100 (BST)
From: Stefano Stabellini <sstabellini@...nel.org>
To: Konrad Rzeszutek Wilk <konrad@...nel.org>
cc: Sinan Kaya <okaya@...eaurora.org>,
Robin Murphy <robin.murphy@....com>,
linux-arm-kernel@...ts.infradead.org, timur@...eaurora.org,
cov@...eaurora.org, nwatters@...eaurora.org,
linux-mips@...ux-mips.org, linux-ia64@...r.kernel.org,
linux-xtensa@...ux-xtensa.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Max Filippov <jcmvbkbc@...il.com>,
Chris Metcalf <cmetcalf@...hip.com>,
Paul Mackerras <paulus@...ba.org>,
"H. Peter Anvin" <hpa@...or.com>, Huacai Chen <chenhc@...ote.com>,
Guan Xuetao <gxt@...c.pku.edu.cn>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Jisheng Zhang <jszhang@...vell.com>,
Florian Fainelli <f.fainelli@...il.com>,
Russell King <linux@....linux.org.uk>,
Aaro Koskinen <aaro.koskinen@....fi>,
Michael Ellerman <mpe@...erman.id.au>, X86 <x86@...nel.org>,
Ingo Molnar <mingo@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Guenter Roeck <linux@...ck-us.net>,
Fenghua Yu <fenghua.yu@...el.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Arnd Bergmann <arnd@...db.de>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Akinobu Mita <akinobu.mita@...il.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Valentin Rothberg <valentinrothberg@...il.com>,
Chris Zankel <chris@...kel.net>,
Tony Luck <tony.luck@...el.com>, linux-pci@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, Dean Nelson <dnelson@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Ralf Baechle <ralf@...ux-mips.org>,
"Suthikulpanit, Suravee" <Suravee.Suthikulpanit@....com>,
Joe Perches <joe@...ches.com>,
Andrew Morton <akpm@...ux-foundation.org>,
sstabellini@...nel.org
Subject: Re: [PATCH 2/3] swiotlb: prefix dma_to_phys and phys_to_dma
functions
On Mon, 28 Mar 2016, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 18, 2016 at 11:00 AM, Sinan Kaya <okaya@...eaurora.org> wrote:
> > On 3/18/2016 8:12 AM, Robin Murphy wrote:
> >> Since we know for sure that swiotlb_to_phys is a no-op on arm64, it might be cleaner to simply not reference it at all. I suppose we could have some private local wrappers, e.g.:
> >>
> >> #define swiotlb_to_virt(addr) phys_to_virt((phys_addr_t)(addr))
> >>
> >> to keep the intent of the code clear (and just in case anyone ever builds a system mad enough to warrant switching out that definition, but I'd hope that never happens).
> >>
> >> Otherwise, looks good - thanks for doing this!
> >
> > OK. I added this. Reviewed-by?
> >
> > I'm not happy to submit such a big patch for all different ARCHs. I couldn't
> > find a cleaner solution. I'm willing to split this patch into multiple if there
> > is a better way.
> >
> > diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> > index ada00c3..8c0f66b 100644
> > --- a/arch/arm64/mm/dma-mapping.c
> > +++ b/arch/arm64/mm/dma-mapping.c
> > @@ -29,6 +29,14 @@
> >
> > #include <asm/cacheflush.h>
> >
> > +/*
> > + * If you are building a system without IOMMU, then you are using SWIOTLB
> > + * library. The ARM64 adaptation of this library does not support address
> > + * translation and it assumes that physical address = dma address for such
> > + * a use case. Please don't build a platform that violates this.
> > + */
>
> Why not just expand the ARM64 part to support address translation?
>
> > +#define swiotlb_to_virt(addr) phys_to_virt((phys_addr_t)(addr))
> > +
>
> Adding Stefano here.
Could you please explain what is the problem that you are trying to
solve? In other words, what is the issue with assuming that physical
address = dma address (and the current dma_to_phys and phys_to_dma
static inlines) if no arm64 platforms violate it? That's pretty much
what is done on x86 too (without X86_DMA_REMAP).
If you want to make sure that the assumption is not violated, you can
introduce a boot time check or a BUG_ON somewhere.
If there is an arm64 platform with phys_addr != dma_addr, we need proper
support for it. In fact even if there is an IOMMU on that platform, when
running Xen on it, the IOMMU would be used by the hypervisor and Linux
would still end up without it, using the swiotlb.
> > static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, pgprot_t prot,
> > bool coherent)
> > {
> > @@ -188,7 +196,7 @@ static void __dma_free(struct device *dev, size_t size,
> > void *vaddr, dma_addr_t dma_handle,
> > struct dma_attrs *attrs)
> > {
> > - void *swiotlb_addr = phys_to_virt(swiotlb_dma_to_phys(dev, dma_handle));
> > + void *swiotlb_addr = swiotlb_to_virt(dma_handle);
> >
> > size = PAGE_ALIGN(size);
> >
> > @@ -209,8 +217,7 @@ static dma_addr_t __swiotlb_map_page(struct device *dev, struct page *page,
> >
> > dev_addr = swiotlb_map_page(dev, page, offset, size, dir, attrs);
> > if (!is_device_dma_coherent(dev))
> > - __dma_map_area(phys_to_virt(swiotlb_dma_to_phys(dev, dev_addr)),
> > - size, dir);
> > + __dma_map_area(swiotlb_to_virt(dev_addr), size, dir);
> >
> > return dev_addr;
> > }
> > @@ -283,8 +290,7 @@ static void __swiotlb_sync_single_for_device(struct device *dev,
> > {
> > swiotlb_sync_single_for_device(dev, dev_addr, size, dir);
> > if (!is_device_dma_coherent(dev))
> > - __dma_map_area(phys_to_virt(swiotlb_dma_to_phys(dev, dev_addr)),
> > - size, dir);
> > + __dma_map_area(swiotlb_to_virt(dev_addr), size, dir);
> > }
> >
> >
> >
> >
> > --
> > Sinan Kaya
> > Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
Powered by blists - more mailing lists