Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757696AbcCUTcA (ORCPT ); Mon, 21 Mar 2016 15:32:00 -0400 Received: from one.firstfloor.org ([193.170.194.197]:37913 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756082AbcCUTb6 (ORCPT ); Mon, 21 Mar 2016 15:31:58 -0400 Date: Mon, 21 Mar 2016 19:54:29 +0100 From: Andi Kleen To: Brian Gerst Cc: Andi Kleen , the arch/x86 maintainers , Andy Lutomirski , Linux Kernel Mailing List , Andi Kleen Subject: Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Message-ID: <20160321185429.GY5083@two.firstfloor.org> References: <1458576969-13309-1-git-send-email-andi@firstfloor.org> <1458576969-13309-5-git-send-email-andi@firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1473 Lines: 35 On Mon, Mar 21, 2016 at 02:49:44PM -0400, Brian Gerst wrote: > On Mon, Mar 21, 2016 at 12:16 PM, Andi Kleen wrote: > > From: Andi Kleen > > > > The kernel needs to explicitely enable RD/WRFSBASE to handle context > > switch correctly. So the application needs to know if it can safely use > > these instruction. Just looking at the CPUID bit is not enough because it > > may be running in a kernel that does not enable the instructions. > > > > One way for the application would be to just try and catch the SIGILL. > > But that is difficult to do in libraries which may not want > > to overwrite the signal handlers of the main application. > > > > So we need to provide a way for the application to discover the kernel > > capability. > > > > I used AT_HWCAP2 in the ELF aux vector which is already used by > > PPC for similar things. We define a new Linux defined bitmap > > returned in AT_HWCAP. Currently it has only one bit set, > > for kernel is FSGSBASE capable. > > > > The application can then access it manually or using > > the getauxval() function in newer glibc. > > How about adding a VDSO function instead? The VDSO can use > alternatives, so it can use the new instructions if supported, or else > use the old syscall. What would be the point of that? It would be a lot more complicated, and I don't see any advantages over the aux vector. vdso also requires custom assembler stubs in the C library. -Andi