[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrX5_3qE0Jmiio6XMKgJ8e7hPnou1+RKGQOgKo5XYruqsQ@mail.gmail.com>
Date: Tue, 18 Nov 2014 10:24:25 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Will Deacon <will.deacon@....com>
Cc: Catalin Marinas <catalin.marinas@....com>, Szabolcs Nagy <nsz@...t70.net>,
Rich Felker <dalias@...c.org>, Russell King <linux@....linux.org.uk>,
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 10:14 AM, Will Deacon <will.deacon@....com> wrote:
> I was really hoping to avoid this thread, but I wanted to comment on the
> suitability of hwcap as a discovery mechanism.
>
> On Tue, Nov 18, 2014 at 10:56:12AM +0000, Catalin Marinas wrote:
>> On Mon, Nov 17, 2014 at 05:38:46PM +0000, Andy Lutomirski wrote:
>> > On Nov 17, 2014 6:39 AM, "Russell King - ARM Linux"
>> > > Given that even cocked these up (just as what happened with the cache
>> > > type register) decoding of the feature type registers depends on the
>> > > underlying CPU architecture.
>> > >
>> > > So, even _if_ we exported the feature registers to userspace, you still
>> > > need to know the CPU architecture to decode them properly, so you still
>> > > need to parse the AT_PLATFORM string to get that information.
>> >
>> > There's no need to expose the hardware feature registers as is.
>> > Define your own sensible feature bits just for Linux.
>>
>> We get regular questions about direct access to the hardware feature
>> bits, many using the x86 cpuid instruction as argument. So far we
>> couldn't see good enough reasons, otherwise we would have pushed such
>> instruction in the ARMv8 architecture. It's also not a simple direct
>> hardware access since the kernel may want to mask some features it does
>> not support, which pretty much requires HWCAP or some banked CPUID
>> registers in hardware.
>
> Or trapping the undef exception from EL0 and emulating it in the kernel,
> which doesn't require any extra hardware, allows the kernel to mask out
> things it can't support and gives userspace the information it needs
> under any scenario.
>
This only sounds reasonable to me if non-Linux architectures do it,
too. Otherwise using a syscall sounds more sensible.
FWIW, I personally don't like the fact that x86 allows unprivileged
code to use CPUID. This can sort of be disabled on some recent Intel
hardware, but last I checked that ability was explicitly not
guaranteed to exist going forward.
>> Another class are dynamic loaders that don't yet have a C library
>> loaded. However, as such loaders are the first entry point, I don't see
>> why they couldn't access auxv directly. One particular scenario here is
>> finding out which CPU micro-architecture (implementation) it is so that
>> the dynamic loader could choose a more optimised library. CPUID would
>> help partially here (get the actual MIDR identifying the CPU
>> implementation rather than just features) but not on heterogeneous
>> systems like big.LITTLE. Which means that we would still be better off
>> with some extra features in auxv, maybe even listing the individual MIDR
>> for all the CPUs in the system.
>
> 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.
Stick it in the vdso? /me snickers
Out of curiosity, why are there 4 bits per feature?
--Andy
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.
