From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6552 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: ARM atomics overhaul for musl Date: Tue, 18 Nov 2014 10:24:25 -0800 Message-ID: References: <20141116055656.GA13940@brightrain.aerifal.cx> <20141116163355.GK4042@n2100.arm.linux.org.uk> <20141116165017.GT22465@brightrain.aerifal.cx> <20141116171055.GM4042@n2100.arm.linux.org.uk> <20141117135412.GC29595@e104818-lin.cambridge.arm.com> <20141117143905.GQ4042@n2100.arm.linux.org.uk> <20141118105611.GC28279@e104818-lin.cambridge.arm.com> <20141118181425.GY18842@arm.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1416335107 22596 80.91.229.3 (18 Nov 2014 18:25:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 18:25:07 +0000 (UTC) Cc: Catalin Marinas , Szabolcs Nagy , Rich Felker , Russell King , Kees Cook , "musl@lists.openwall.com" , "linux-arm-kernel@lists.infradead.org" To: Will Deacon Original-X-From: musl-return-6564-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 18 19:25:00 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XqnSV-0000lx-Ip for gllmg-musl@m.gmane.org; Tue, 18 Nov 2014 19:24:59 +0100 Original-Received: (qmail 17595 invoked by uid 550); 18 Nov 2014 18:24:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17586 invoked from network); 18 Nov 2014 18:24:57 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WR90iGbV5Bk0n2MRU1PVx5d/HRg4cexa8fezxeq6t0Y=; b=JWbr8veH4iFcU5TXYYuWT3QmjgZq5Me8O+APExHvD6fMPUyb07LcCKJfL6euzAB5AR B34rcFUbpCasYRtcO3VYpBOSMORuFlAniu8ktDnran1ybpQZXAscm0TUY4n6kd9Bk0JG dmYoetDwshzKoRSE23a2c4pxvt/hJlbyv+HKfDnkhymbmGJYoN7K7BTK9hZct/5+JgO2 93SLhhAzVMjH1Lhh9gosgY/60DgMGty1hoP+4p+uUlGVuiItu/eyDlucIiFcwhROGwqh /749N/h/oZg1fKTemsGY9D4fDNBhwIrAMEJoqVOIgZQrV+xUNhuZ8XRzc8p/ogyoAa/j 26xA== X-Gm-Message-State: ALoCoQkQasF8nSrIvuUzTXmqY53klgwjOxxWIMOeJ6qk1Wmg1kt5rcuX3MJDiSWRk4RUmzbsU89d X-Received: by 10.152.203.196 with SMTP id ks4mr457496lac.78.1416335085989; Tue, 18 Nov 2014 10:24:45 -0800 (PST) In-Reply-To: <20141118181425.GY18842@arm.com> Xref: news.gmane.org gmane.linux.lib.musl.general:6552 gmane.linux.ports.arm.kernel:373128 Archived-At: On Tue, Nov 18, 2014 at 10:14 AM, Will Deacon 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