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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 15 Mar 2011 10:45:50 +0900
From:	InKi Dae <daeinki@...il.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	KyongHo Cho <pullip.cho@...sung.com>,
	Tomasz Stanislawski <t.stanislaws@...sung.com>,
	k.debski@...sung.com, linux-samsung-soc@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>,
	°­¹Î±Ô <mk7.kang@...sung.com>,
	linux-kernel@...r.kernel.org,
	´ëÀαâ <inki.dae@...sung.com>,
	kyungmin.park@...sung.com, kgene.kim@...sung.com,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
	linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver

2011/3/14 Russell King - ARM Linux <linux@....linux.org.uk>:
> On Mon, Mar 14, 2011 at 09:37:51PM +0900, KyongHo Cho wrote:
>> I have also noticed that dma_map_single/page/sg() can map physical
>> memory into an arbitrary device address region.
>> But it is not enough solution for various kinds of IOMMUs.
>> As Kukjin Kim addressed, we need to support larger page size than 4KB
>> because we can reduce TLB miss when we have larger page size.
>>
>> Our IOMMU(system mmu) supports all page size of ARM architecture
>> including 16MB, 1MB, 64KB and 4KB.
>> Since the largest size supported by buddy system of 32-bit architecture is 4MB,
>> our system support all page sizes except 16MB.
>> We proved that larger page size is helpful for DMA performance
>> significantly (more than 10%, approximately).
>> Big page size is not a problem for peripheral devices
>> because their address space is not suffer from external fragmentation.
>
> 1. dma_map_single() et.al. is used for mapping *system* *RAM* for devices
>   using whatever is necessary.  It must not be used for trying to setup
>   arbitary other mappings.
>
> 2. It doesn't matter where the memory for dma_map_single() et.al. comes
>   from provided the virtual address is a valid system RAM address or
>   the struct page * is a valid struct page in the memory map (iow, you
>   can't create this yourself.)

You mean that we cannot have arbitrary virtual address mapping for
iommu based device?
actually, we have memory mapping to arbitrary device virtual address
space, not kernel virtual address space.

>
> 3. In the case of an IOMMU, the DMA API does not limit you to only using
>   4K pages to setup the IOMMU mappings.  You can use whatever you like
>   provided the hardware can cope with it.  You can coalesce several
>   existing entries together provided you track what you're doing and can
>   undo what's been done when the mapping is no longer required.
>
> So really there's no reason not to use 64K, 1M and 16M IOMMU entries if
> that's the size of buffer which has been passed to the DMA API.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists