Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757892AbcCUTtU (ORCPT ); Mon, 21 Mar 2016 15:49:20 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34720 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756606AbcCUTtT (ORCPT ); Mon, 21 Mar 2016 15:49:19 -0400 MIME-Version: 1.0 In-Reply-To: <1458576969-13309-5-git-send-email-andi@firstfloor.org> References: <1458576969-13309-1-git-send-email-andi@firstfloor.org> <1458576969-13309-5-git-send-email-andi@firstfloor.org> Date: Mon, 21 Mar 2016 14:49:44 -0400 Message-ID: Subject: Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 From: Brian Gerst To: Andi Kleen Cc: "the arch/x86 maintainers" , Andy Lutomirski , Linux Kernel Mailing List , Andi Kleen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1185 Lines: 29 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. -- Brian Gerst