[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141118191936.GE4042@n2100.arm.linux.org.uk>
Date: Tue, 18 Nov 2014 19:19:36 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Will Deacon <will.deacon@....com>
Cc: Catalin Marinas <catalin.marinas@....com>,
Andy Lutomirski <luto@...capital.net>,
Szabolcs Nagy <nsz@...t70.net>, Rich Felker <dalias@...c.org>,
Kees Cook <keescook@...omium.org>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: ARM atomics overhaul for musl
On Tue, Nov 18, 2014 at 06:14:25PM +0000, Will Deacon wrote:
> The only way I can see hwcap working is if we follow what the architecture
> allows for in ARMv8, which is 4 bits per feature over (currently) around
> 10 32-bit registers. That would mean potentially exposing 1280 hwcaps,
> which is clearly insane.
Exactly my argument, which got called "rediculous" ! I'm glad that
someone with a similar visibility of the problem has come to the
same conclusion that I did.
> We've done a bit better with the crypto extensions, where we provide
> fine-grained sha1, sha2 etc hwcaps, but this is based on the relavant 4-bit
> fields in ISAR5 being positive values. I can't find any architectural
> guarantees that this will work on future cores (e.g. bumping the 4-bit
> field to indicate a subset of previous functionality).
This is the big problem. An example of this is the barrier bits, which
indicate whether dmb & dsb are present or not. It's not a single bit,
but a group of four. If we provide a single bit for dmb, and another
for dsb (to cater for a future possibility that dmb or dsb may be
separately indicated by a future 4-bit binary pattern), that's fine,
but should we then list every instruction which is conditional on any
ISAR bit pattern? That becomes a /very/ big space indeed.
If we don't do this, and (eg) we use a single bit for both dmb and dsb,
what if a future bit pattern indicates that (eg) dmb is obsolete, but
dsb hasn't.
Contary to what others assert, this is not a trivial problem, and it's
not trivial to just add additional hwcap bits to solve it.
There's also the problem in /knowing/ what information to export to
userspace, before userspace knows that they need it... which is exactly
what's happened with DMB (and this is not the first time it's happened.)
I suspect this won't be the last time either.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
