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.