- 19 May, 2015 40 commits
-
-
Ingo Molnar authored
mxcsr_feature_mask_init() depends on TS being cleared, as it executes an FXSAVE instruction. After later changes we will move the TS setup into fpu__init_cpu(), which will interact with this - so clear the TS flag explicitly. 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 fpu__ctx_switch_init() has two aspects: a once per bootup functionality that sets up a capability flag, and a per CPU functionality that sets CR0::TS. Split the function. Note that at this stage we still have duplicate calls into these methods, as both the _system() and the _cpu() methods are run on all CPUs, with lower level on_boot_cpu flags filtering out the duplicates where needed. So add TS flag clearing as well, to handle the aftermath of early CPU init sequences that might call in without having eager-fpu set - don't assume the TS flag is cleared. Calling each from its respective init level will happen later on. Reviewed-by:
-
Ingo Molnar authored
It's not an xsave specific function anymore, so rename it accordingly and also clean it up a bit: - remove the obsolete __init_refok, as the code paths are not mixed anymore - rename it from eager_fpu_init() to fpu__ctx_switch_init() - remove stray 'return;' - make it static to its only user Reviewed-by:
-
Ingo Molnar authored
Move eager_fpu_init() and the 'eagerfpu' boot parameter handling function to the generic FPU init file: it's generic FPU functionality. Reviewed-by:
-
Ingo Molnar authored
The FPU context switch type (lazy or eager) setup code is split into two places currently - move it all to eager_fpu_init(). Note that the code we move will now be executed on non-xstate CPUs as well, but this should be safe: both xfeatures_mask and cpu_has_xsaveopt is 0 there. Reviewed-by:
-
Ingo Molnar authored
It's a pure xstate method now, no need for this duplicate call. Reviewed-by:
-
Ingo Molnar authored
The legacy FPU init image is used on older CPUs who don't run xstate init. But the init code is called within setup_init_fpu_buf(), an xstate method. Move this legacy init out of the xstate code and put it into fpu/init.c. Reviewed-by:
-
Ingo Molnar authored
Only call xstate system setup routines from fpu__init_system(). Likewise, don't call fpu__init_cpu_xstate() from fpu__init_system(). Reviewed-by:
-
Ingo Molnar authored
Expand fpu__init_system_xstate() and fpu__init_cpu_xstate() calls into xsave_init() calls. (This will allow us to call the proper versions in higher level FPU init code later on.) No change in functionality. Reviewed-by:
-
Ingo Molnar authored
Linearize the call sequence in xsave_init(): fpu__init_system_xstate(); fpu__init_cpu_xstate(); We do this by propagating the boot-once quirk into fpu__init_system_xstate(). fpu__init_cpu_xstate() is safe to be called multiple time. Reviewed-by:
-
Ingo Molnar authored
Now that legacy code can execute fpu__init_cpu_xstate() in xsave_init(), we can move the once per boot legacy check into fpu__init_system_xstate(), where it belongs. Reviewed-by:
-
Ingo Molnar authored
fpu__init_system_xstate() does an FPU capability check that is better done in fpu__init_cpu_xstate(). This will allow us to call fpu__init_cpu_xstate() directly on legacy CPUs as well. Reviewed-by:
-
Ingo Molnar authored
Rename existing xstate init functions along the system/cpu init principles: fpu__init_system_xstate(): called once per system bootup fpu__init_cpu_xstate(): called per CPU onlining Also make the fpu__init_cpu_xstate() early code invariant: if xfeatures_mask is not set yet then don't crash but return. Reviewed-by:
-
Ingo Molnar authored
There are two kinds of FPU initialization sequences necessary to bring FPU functionality up: once per system bootup activities, such as detection, feature initialization, etc. of attributes that are shared by all CPUs in the system - and per cpu initialization sequences run when a CPU is brought online (either during bootup or during CPU hotplug onlining), such as CR0/CR4 register setting, etc. The FPU code is mixing these roles together, with no clear distinction. Start sorting this out by splitting the main FPU detection routine (fpu__cpu_init()) into two parts: fpu__init_system() for one per system init activities, and fpu__init_cpu() for the per CPU onlining init activities. Note that xstate_init() is called from both variants for the time being, because it has a dual nature as well. We'll fix that in upcoming patches. Just do the split and call it as we used to before, don't introduce any change in initialization behavior yet, beyond duplicate (and harmless) fpu__init_cpu() and xstate_init() calls - which we'll fix in later patches. Reviewed-by:
-
Ingo Molnar authored
Make init_xstate_buf allocated statically at build time. This structure's maximum size is around 1KB - and it's allocated even on most modern embedded x86 CPUs which strive for FPU instruction set parity with desktop and server CPUs, so it's not like we can save much on smaller systems. This removes the last bootmem allocation from the FPU init path, allowing it to be called earlier in the boot sequence. Reviewed-by:
-
Ingo Molnar authored
Remove the dependency on the init_xstate_buf == NULL check to implement once-per-bootup logic in eager_fpu_init(), by making setup_init_fpu_buf() run once per bootup explicitly. This is in preparation to make init_xstate_buf statically allocated. The various boot-once quirks in the FPU init code will be removed in a later cleanup stage. Reviewed-by:
-
Ingo Molnar authored
There's only 8 xstate bits at the moment, and it's not like we can support unknown bits - so put xstate_offsets[] and xstate_sizes[] into static allocation. This is in preparation to be able to call the FPU init code earlier, when there's no bootmem available yet. Reviewed-by:
-
Ingo Molnar authored
fpstate_xstate_init_size() is called in fpu__cpu_init(), which is run on every CPU, every time they are brought online. But we want to call fpstate_xstate_init_size() only once. Move it to fpu__detect(), which only runs once, on the boot CPU. Also clean up the flow of fpstate_xstate_init_size() a bit, by removing a 'return' from the middle of the function. Reviewed-by:
-
Ingo Molnar authored
Propagate the 'fpu->fpregs_active' naming to the high level function that clears it. Reviewed-by:
-
Ingo Molnar authored
Propagate the 'fpu->fpregs_active' naming to the high level function that sets it. Reviewed-by:
-
Ingo Molnar authored
Propagate the 'fpu->fpregs_active' naming to the functions that clears it. Reviewed-by:
-
Ingo Molnar authored
Propagate the 'fpu->fpregs_active' naming to the functions that sets it. Reviewed-by:
-
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:
-
