Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1362103
| From | Brian Gerst <brgerst@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 |
| Date | 2016-03-21 20:40 +0100 |
| Message-ID | <rfdQe-1Ku-13@gated-at.bofh.it> (permalink) |
| References | <rfaIF-8aj-3@gated-at.bofh.it> <rfaIG-8aj-23@gated-at.bofh.it> <rfdQe-1Ku-15@gated-at.bofh.it> <rfdQe-1Ku-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, Mar 21, 2016 at 2:54 PM, Andi Kleen <andi@firstfloor.org> wrote: > On Mon, Mar 21, 2016 at 02:49:44PM -0400, Brian Gerst wrote: >> On Mon, Mar 21, 2016 at 12:16 PM, Andi Kleen <andi@firstfloor.org> wrote: >> > From: Andi Kleen <ak@linux.intel.com> >> > >> > 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 It would be less complicated actually, as normal userspace would just continue to call arch_prctl() as it does today. Glibc would implement arch_prctl() just like it does with gettimeofday() -- with an ifunc selector [1] that calls the VDSO function if it is available, or the syscall if not. No custom assembly needed. [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86/gettimeofday.c;h=36f7c26ffb0e818709d032c605fec8c4bd22a14e;hb=HEAD -- Brian Gerst
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Andi Kleen <andi@firstfloor.org> - 2016-03-21 17:20 +0100
Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Brian Gerst <brgerst@gmail.com> - 2016-03-21 20:40 +0100
Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Andi Kleen <andi@firstfloor.org> - 2016-03-21 20:50 +0100
Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Andy Lutomirski <luto@amacapital.net> - 2016-03-21 23:20 +0100
Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Andi Kleen <andi@firstfloor.org> - 2016-03-21 20:40 +0100
Re: [PATCH 4/9] x86: Enumerate kernel FSGS capability in AT_HWCAP2 Brian Gerst <brgerst@gmail.com> - 2016-03-21 20:50 +0100
csiph-web