linux-kernel - Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi

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]

Message-ID: <3507881.xd2FjVJzjC@wuerfel>
Date:	Tue, 24 Nov 2015 22:11:57 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Stephen Boyd <sboyd@...eaurora.org>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Peter Maydell <peter.maydell@...aro.org>,
	Måns Rullgård <mans@...sr.com>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Christopher Covington <cov@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

On Tuesday 24 November 2015 20:35:16 Russell King - ARM Linux wrote:
> We'd need to do something similar for v7VE as well.  As we're getting
> more of this, I'd suggest we move to:
> 
> arch-v7a-y                      =$(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)
> arch-v7a-$(CONFIG_CPU_32v7VE)   =... whatever it was...
> arch-$(CONFIG_CPU_32v7)         =-D__LINUX_ARM_ARCH__=7 $(arch-v7a-y)
> arch-v6-y                       =$(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6)
> arch-v6-$(CONFIG_CPU_32v6K)     =$(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k)
> arch-$(CONFIG_CPU_32v6)         =-D__LINUX_ARM_ARCH__=6 $(arch-v6-y)

I would argue that V7VE is different from V6K here: The instructions
that are added in V6K compared to V6 are not generated by gcc but
are typically used in assembly like

static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size)
{
...
#ifndef CONFIG_CPU_V6
	asm volatile(...); /* v6k specific instruction */
#endif
}

while the logic in your example above would break normal v7 support when
both V7 and V7VE are enabled.

> > My understanding is that we want to support CPU_V7VE without
> > CPU_V7 enabled so that it uses the idiv instructions in that
> > configuration. When V7VE and V7 are both enabled, we should
> > degrade to the aeabi functions, and the same is true for when
> > V7VE is disabled.
> 
> Let me have another look at this, it's been a while since I touched these
> options...

There is one idea that I've had in the back of my mind for a long
while, and probably mentioned on the list before:

We could decide to simplify the CPU architecture selection for
multiplatform a lot if we turn the somewhat overengineered ARCH_MULTI_*
options into a choice statement, where each of them implies the
higher architecture levels. That way we can linearize
ARMv6/v6k/v7/v7VE/v8/v8.1 so that you just pick which platforms you
want to see by selecting the minimum level, and all higher ones will
automatically be available (for v8 and v8.1 that means just MACH_VIRT,
as we don't really want to run 32-bit kernels on bare metal v8-A
machines).

That way, we can have LPAE and -march=armv7ve support depend on
CONFIG_ARCH_MULTI_V7VE, which would imply that we don't support
CPU_V7 based platforms.

	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/