linux-kernel - Re: [PATCH] ARM: use default ioremap alignment for SMP or LPAE

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] [day] [month] [year] [list]

Date:	Fri, 23 Jan 2015 16:31:51 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Catalin Marinas <catalin.marinas@....com>,
	"nicolas.pitre@...aro.org" <nicolas.pitre@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Sergey Dyasly <s.dyasly@...sung.com>,
	Dmitry Safonov <d.safonov@...tner.samsung.com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	James Bottomley <JBottomley@...allels.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Arnd Bergmann <arnd.bergmann@...aro.org>,
	Guan Xuetao <gxt@...c.pku.edu.cn>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] ARM: use default ioremap alignment for SMP or LPAE

On Friday 23 January 2015 14:52:36 Catalin Marinas wrote:
> On Thu, Jan 22, 2015 at 11:03:00AM +0000, Arnd Bergmann wrote:
> > Unrelated to this question however is whether we want to keep
> > supersection mappings as a performance optimization to save TLBs.
> > It seems useful to me, but not critical.
> 
> Currently in Linux we allow 16MB mappings only if the phys address is
> over 32-bit and !LPAE which makes it unlikely for normal RAM with
> pre-LPAE hardware.

Ah, I missed this part when looking at the code.

> IIRC a bigger problem was that supersections are optional in the
> architecture but there was no CPUID bit field in ARMv6 (and early ARMv7)
> to check for their presence. The ID_MMFR3 contains this information but
> for example on early Cortex-A8 that bitfield was reserved and the TRM
> states "unpredictable" on read (so probably zero in practice).
> 
> On newer ARMv7 (not necessarily with LPAE), we could indeed revisit the
> 16MB section mapping but it won't go well with single zImage if you want
> to support earlier ARMv7 or ARMv6.

I see. If there is desire to have it as an optimization, we could do
it for armv7ve-only kernels. We don't currently have an build-time
option for those, but we should introduce one anyway, in order to
better make use of the idiv instructions and to prevent one from
enabling LPAE on a multiplatform kernel that contains pre-lpae armv7
machines (Cortex a8/a9/a5, and some others I'm not sure about).

	Arnd
--
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/