- 19 May, 2015 40 commits
-
-
Ingo Molnar authored
Propagate the 'fpu->fpregs_active' naming to the functions that sets it. Reviewed-by:
Borislav Petkov <bp@alien8.de> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Ingo Molnar authored
So the current code uses fpu->has_cpu to determine whether a given user FPU context is actively loaded into the FPU's registers [*] and that those registers represent the task's current FPU state. But this term is not unambiguous: especially the distinction between fpu->has_fpu, PF_USED_MATH and fpu_fpregs_owner_ctx is not clear. Increase clarity by unambigously signalling that it's about hardware registers being active right now, by renaming it to fpu->fpregs_active. ( In later patches we'll use more of the 'fpregs' naming, which will make it easier to grep for as well. ) [*] There's the kernel_fpu_begin()/end() primitive that also activates FPU hw registers as well and uses them, without touching the fpu->fpregs_active flag. Reviewed-by: -
Ingo Molnar authored
Improve the comments and add new ones, as this code isn't very obvious. Reviewed-by:
-
Ingo Molnar authored
The previous explanation was rather cryptic. Also transform "u32 [64]" to the more readable "u8[256]" form. No change in implementation. Reviewed-by:
-
Ingo Molnar authored
Rename regset accessors to prefix them with 'regset_', because we want to start using the 'fpregs_active' name elsewhere. Reviewed-by:
-
Ingo Molnar authored
The code has the following problems: - it uses a single global 'fx_scratch' area that multiple CPUs could write into simultaneously, in theory. - it wastes 512 bytes of .data for something that is only rarely used. Fix this by moving the state buffer to the stack. Note that while this is 512 bytes, we don't ever call this function in very deep callchains, so its stack usage should not be a problem. Also add comments to explain the magic 0x0000ffbf default value. Reviewed-by:
-
Ingo Molnar authored
'xsave.header::xstate_bv' is a misnomer - what does 'bv' stand for? It probably comes from the 'XGETBV' instruction name, but I could not find in the Intel documentation where that abbreviation comes from. It could mean 'bit vector' - or something else? But how about - instead of guessing about a weird name - we named the field in an obvious and descriptive way that tells us exactly what it does? So rename it to 'xfeatures', which is a bitmask of the xfeatures that are fpstate_active in that context structure. Eyesore like: fpu->state->xsave.xsave_hdr.xstate_bv |= XSTATE_FP; is now much more readable: fpu->state->xsave.header.xfeatures |= XSTATE_FP; Which form is not just infinitely more readable, but is also shorter as well. Reviewed-by: -
Ingo Molnar authored
Code like: fpu->state->xsave.xsave_hdr.xstate_bv |= XSTATE_FP; is an eyesore, because not only is the words 'xsave' and 'state' are repeated twice times (!), but also because of the 'hdr' and 'bv' abbreviations that are pretty meaningless at a first glance. Start cleaning this up by renaming 'xsave_hdr' to 'header'. Reviewed-by: -
Ingo Molnar authored
Clean up various regset handlers: use the 'fpu' pointer which is available in most cases. Reviewed-by:
-
Ingo Molnar authored
The suspend code accesses FPU state internals, add a helper for it and isolate it. Reviewed-by:
-
Ingo Molnar authored
The name 'xstate_features' does not tell us whether it's a bitmap or any other value. That it's a count of features is only obvious if you read the code that calculates it. Rename it to the more descriptive 'xfeatures_nr' name. Reviewed-by:
-
Ingo Molnar authored
So the 'pcntxt_mask' is a misnomer, it's essentially meaningless to anyone who doesn't know what it does exactly. Name it more descriptively as 'xfeatures_mask'. Reviewed-by:
-
Ingo Molnar authored
Inform the user/admin about which xstate features the kernel supports. Reviewed-by:
-
Ingo Molnar authored
Standardize the various boot time messages printed during FPU detection: - Use a common 'x86/fpu: ' prefix for consistency and to make it easy to grep boot logs for FPU related messages - Correct speling errors - Add printout for the legacy FPU case as well - Clarify messages Reviewed-by:
-
Ingo Molnar authored
asm/fpu/api.h does not contain any defines useful to assembly code, and no assembly code includes asm/fpu/api.h. Remove the historic #ifndef __ASSEMBLY__ leftover guard. Reviewed-by:
-
Ingo Molnar authored
So this code surprised me - and being surprised when reading FPU code does not help maintainability of an already overly complex subsystem. Remove the obfuscation and just don't use __init annotation for now. Anyone who wants to free these ~600 bytes of xstate_enable_boot_cpu() should implement it cleanly. Reviewed-by:
-
Ingo Molnar authored
fpu/types.h gets included everywhere, move the MXCSR_DEFAULT to fpu/internal.h, the place where it's used. Reviewed-by:
-
Ingo Molnar authored
This unifies all the FPU related header files under a unified, hiearchical naming scheme: - asm/fpu/types.h: FPU related data types, needed for 'struct task_struct', widely included in almost all kernel code, and hence kept as small as possible. - asm/fpu/api.h: FPU related 'public' methods exported to other subsystems. - asm/fpu/internal.h: FPU subsystem internal methods - asm/fpu/xsave.h: XSAVE support internal methods (Also standardize the header guard in asm/fpu/internal.h.) Reviewed-by: -
Ingo Molnar authored
Move the xsave.h header file to the FPU directory as well. Reviewed-by:
-
Ingo Molnar authored
We already have fpu/types.h, move i387.h to fpu/api.h. The file name has become a misnomer anyway: it offers generic FPU APIs, but is not limited to i387 functionality. Reviewed-by:
-
Ingo Molnar authored
Reviewed-by:
-
Ingo Molnar authored
The primary purpose of this function is to clear the current task's FPU before an exec(), to not leak information from the previous task, and to allow the new task to start with freshly initialized FPU registers. Rename the function to reflect this primary purpose. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
This helper function is only used in fpu/core.c, move it there. This slightly speeds up compilation. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Also rename it to fpu_want_lazy_restore(), to better indicate that this function just tests whether we can do a lazy restore. (The old name suggested that it was doing the lazy restore, which is not the case.) Reviewed-by:
-
Ingo Molnar authored
Replace task_disable_lazy_fpu_restore() with easier to read open-coded uses: we already update the fpu->last_cpu field explicitly in other cases. (This also removes yet another task_struct using FPU method.) Better explain the fpu::last_cpu field in the structure definition. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
Ingo Molnar authored
Introduce a simple fpu->fpstate_active flag in the fpu context data structure and use that instead of PF_USED_MATH in task->flags. Testing for this flag byte should be slightly more efficient than testing a bit in a bitmask, but the main advantage is that most FPU functions can now be performed on a 'struct fpu' alone, they don't need access to 'struct task_struct' anymore. There's a slight linecount increase, mostly due to the 'fpu' local variables and due to extra comments. The local variables will go away once we move most of the FPU methods to pure 'struct fpu' parameters. Reviewed-by:
-
Ingo Molnar authored
Explain its usage and also document a TODO item. Reviewed-by:
-
Ingo Molnar authored
PF_USED_MATH is used directly, but also in a handful of helper inlines. To ease the elimination of PF_USED_MATH, convert all inline helpers to open-coded PF_USED_MATH usage. Reviewed-by:
-
Ingo Molnar authored
Migrate this function to pure 'struct fpu' usage. Reviewed-by:
-
