1. 05 May, 2014 2 commits
  2. 07 Mar, 2014 1 commit
    • Steven Rostedt's avatar
      x86: Keep thread_info on thread stack in x86_32 · 198d208d
      Steven Rostedt authored
      x86_64 uses a per_cpu variable kernel_stack to always point to
      the thread stack of current. This is where the thread_info is stored
      and is accessed from this location even when the irq or exception stack
      is in use. This removes the complexity of having to maintain the
      thread info on the stack when interrupts are running and having to
      copy the preempt_count and other fields to the interrupt stack.
      x86_32 uses the old method of copying the thread_info from the thread
      stack to the exception stack just before executing the exception.
      Having the two different requires #ifdefs and also the x86_32 way
      is a bit of a pain to maintain. By converting x86_32 to the same
      method of x86_64, we can remove #ifdefs, clean up the x86_32 code
      a little, and remove the overhead of the copy.
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/20110806012354.263834829@goodmis.org
      Link: http://lkml.kernel.org/r/20140206144321.852942014@goodmis.org
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  3. 27 Feb, 2014 2 commits
  4. 13 Feb, 2014 1 commit
  5. 03 Jan, 2014 1 commit
  6. 26 Oct, 2013 1 commit
    • Jan Beulich's avatar
      x86/cpu: Track legacy CPU model data only on 32-bit kernels · 09dc68d9
      Jan Beulich authored
      struct cpu_dev's c_models is only ever set inside CONFIG_X86_32
      conditionals (or code that's being built for 32-bit only), so
      there's no use of reserving the (empty) space for the model
      names in a 64-bit kernel.
      Similarly, c_size_cache is only used in the #else of a
      CONFIG_X86_64 conditional, so reserving space for (and in one
      case even initializing) that field is pointless for 64-bit
      kernels too.
      While moving both fields to the end of the structure, I also
      noticed that:
       - the c_models array size was one too small, potentially causing
         table_lookup_model() to return garbage on Intel CPUs (intel.c's
         instance was lacking the sentinel with family being zero), so the
         patch bumps that by one,
       - c_models' vendor sub-field was unused (and anyway redundant
         with the base structure's c_x86_vendor field), so the patch deletes it.
      Also rename the legacy fields so that their legacy nature stands out
      and comment their declarations.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Link: http://lkml.kernel.org/r/5265036802000078000FC4DB@nat28.tlf.novell.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  7. 25 Sep, 2013 1 commit
  8. 06 Aug, 2013 1 commit
  9. 14 Jul, 2013 1 commit
    • Paul Gortmaker's avatar
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker authored
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      [1] https://lkml.org/lkml/2013/5/20/589
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
  10. 21 Jun, 2013 5 commits
    • Seiji Aguchi's avatar
      x86, trace: Add irq vector tracepoints · cf910e83
      Seiji Aguchi authored
      [Purpose of this patch]
      As Vaibhav explained in the thread below, tracepoints for irq vectors
      are useful.
      The current interrupt traces from irq_handler_entry and irq_handler_exit
      provide when an interrupt is handled.  They provide good data about when
      the system has switched to kernel space and how it affects the currently
      running processes.
      There are some IRQ vectors which trigger the system into kernel space,
      which are not handled in generic IRQ handlers.  Tracing such events gives
      us the information about IRQ interaction with other system events.
      The trace also tells where the system is spending its time.  We want to
      know which cores are handling interrupts and how they are affecting other
      processes in the system.  Also, the trace provides information about when
      the cores are idle and which interrupts are changing that state.
      On the other hand, my usecase is tracing just local timer event and
      getting a value of instruction pointer.
      I suggested to add an argument local timer event to get instruction pointer before.
      But there is another way to get it with external module like systemtap.
      So, I don't need to add any argument to irq vector tracepoints now.
      [Patch Description]
      Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
      But there is an above use case to trace specific irq_vector rather than tracing all events.
      In this case, we are concerned about overhead due to unwanted events.
      So, add following tracepoints instead of introducing irq_vector_entry/exit.
      so that we can enable them independently.
         - local_timer_vector
         - reschedule_vector
         - call_function_vector
         - call_function_single_vector
         - irq_work_entry_vector
         - error_apic_vector
         - thermal_apic_vector
         - threshold_apic_vector
         - spurious_apic_vector
         - x86_platform_ipi_vector
      Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
      makes a zero when tracepoints are disabled. Detailed explanations are as follows.
       - Create trace irq handlers with entering_irq()/exiting_irq().
       - Create a new IDT, trace_idt_table, at boot time by adding a logic to
         _set_gate(). It is just a copy of original idt table.
       - Register the new handlers for tracpoints to the new IDT by introducing
         macros to alloc_intr_gate() called at registering time of irq_vector handlers.
       - Add checking, whether irq vector tracing is on/off, into load_current_idt().
         This has to be done below debug checking for these reasons.
         - Switching to debug IDT may be kicked while tracing is enabled.
         - On the other hands, switching to trace IDT is kicked only when debugging
           is disabled.
      In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
      used for other purposes.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.com
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
    • Seiji Aguchi's avatar
      x86: Rename variables for debugging · 629f4f9d
      Seiji Aguchi authored
      Rename variables for debugging to describe meaning of them precisely.
      Also, introduce a generic way to switch IDT by checking a current state,
      debug on/off.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C323A8.7050905@hds.com
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
    • Borislav Petkov's avatar
      x86: Add a static_cpu_has_safe variant · 4a90a99c
      Borislav Petkov authored
      We want to use this in early code where alternatives might not have run
      yet and for that case we fall back to the dynamic boot_cpu_has.
      For that, force a 5-byte jump since the compiler could be generating
      differently sized jumps for each label.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1370772454-6106-5-git-send-email-bp@alien8.de
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
    • Borislav Petkov's avatar
      x86: Sanity-check static_cpu_has usage · 5700f743
      Borislav Petkov authored
      static_cpu_has may be used only after alternatives have run. Before that
      it always returns false if constant folding with __builtin_constant_p()
      doesn't happen. And you don't want that.
      This patch is the result of me debugging an issue where I overzealously
      put static_cpu_has in code which executed before alternatives have run
      and had to spend some time with scratching head and cursing at the
      So add a jump to a warning which screams loudly when we use this
      function too early. The alternatives patch that check away in
      conjunction with patching the rest of the kernel image.
      [ hpa: factored this into its own configuration option.  If we want to
        have an overarching option, it should be an option which selects
        other options, not as a group option in the source code. ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1370772454-6106-4-git-send-email-bp@alien8.de
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
    • Borislav Petkov's avatar
      x86, cpu: Add a synthetic, always true, cpu feature · c3b83598
      Borislav Petkov authored
      This will be used in alternatives later as an always-replace flag.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1370772454-6106-2-git-send-email-bp@alien8.de
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  11. 06 Jun, 2013 1 commit
  12. 02 Apr, 2013 1 commit
  13. 31 Jan, 2013 2 commits
  14. 29 Nov, 2012 1 commit
  15. 14 Nov, 2012 1 commit
  16. 27 Sep, 2012 1 commit
    • H. Peter Anvin's avatar
      x86, smep, smap: Make the switching functions one-way · b2cc2a07
      H. Peter Anvin authored
      There is no fundamental reason why we should switch SMEP and SMAP on
      during early cpu initialization just to switch them off again.  Now
      with %eflags and %cr4 forced to be initialized to a clean state, we
      only need the one-way enable.  Also, make the functions inline to make
      them (somewhat) harder to abuse.
      This does mean that SMEP and SMAP do not get initialized anywhere near
      as early.  Even using early_param() instead of __setup() doesn't give
      us control early enough to do this during the early cpu initialization
      phase.  This seems reasonable to me, because SMEP and SMAP should not
      matter until we have userspace to protect ourselves from, but it does
      potentially make it possible for a bug involving a "leak of
      permissions to userspace" to get uncaught.
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
  17. 21 Sep, 2012 2 commits
  18. 19 Sep, 2012 1 commit
  19. 18 Sep, 2012 1 commit
  20. 13 Sep, 2012 1 commit
  21. 08 Aug, 2012 1 commit
  22. 07 Aug, 2012 2 commits
  23. 28 Jun, 2012 2 commits
    • Alex Shi's avatar
      x86/tlb: add tlb_flushall_shift for specific CPU · c4211f42
      Alex Shi authored
      Testing show different CPU type(micro architectures and NUMA mode) has
      different balance points between the TLB flush all and multiple invlpg.
      And there also has cases the tlb flush change has no any help.
      This patch give a interface to let x86 vendor developers have a chance
      to set different shift for different CPU type.
      like some machine in my hands, balance points is 16 entries on
      Romely-EP; while it is at 8 entries on Bloomfield NHM-EP; and is 256 on
      IVB mobile CPU. but on model 15 core2 Xeon using invlpg has nothing
      For untested machine, do a conservative optimization, same as NHM CPU.
      Signed-off-by: default avatarAlex Shi <alex.shi@intel.com>
      Link: http://lkml.kernel.org/r/1340845344-27557-5-git-send-email-alex.shi@intel.com
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
    • Alex Shi's avatar
      x86/tlb_info: get last level TLB entry number of CPU · e0ba94f1
      Alex Shi authored
      For 4KB pages, x86 CPU has 2 or 1 level TLB, first level is data TLB and
      instruction TLB, second level is shared TLB for both data and instructions.
      For hupe page TLB, usually there is just one level and seperated by 2MB/4MB
      and 1GB.
      Although each levels TLB size is important for performance tuning, but for
      genernal and rude optimizing, last level TLB entry number is suitable. And
      in fact, last level TLB always has the biggest entry number.
      This patch will get the biggest TLB entry number and use it in furture TLB
      Accroding Borislav's suggestion, except tlb_ll[i/d]_* array, other
      function and data will be released after system boot up.
      For all kinds of x86 vendor friendly, vendor specific code was moved to its
      specific files.
      Signed-off-by: default avatarAlex Shi <alex.shi@intel.com>
      Link: http://lkml.kernel.org/r/1340845344-27557-2-git-send-email-alex.shi@intel.com
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
  24. 07 Jun, 2012 1 commit
  25. 01 Jun, 2012 1 commit
    • Steven Rostedt's avatar
      x86: Allow nesting of the debug stack IDT setting · f8988175
      Steven Rostedt authored
      When the NMI handler runs, it checks if it preempted a debug handler
      and if that handler is using the debug stack. If it is, it changes the
      IDT table not to update the stack, otherwise it will reset the debug
      stack and corrupt the debug handler it preempted.
      Now that ftrace uses breakpoints to change functions from nops to
      callers, many more places may hit a breakpoint. Unfortunately this
      includes some of the calls that lockdep performs. Which causes issues
      with the debug stack. It too needs to change the debug stack before
      tracing (if called from the debug handler).
      Allow the debug_stack_set_zero() and debug_stack_reset() to be nested
      so that the debug handlers can take advantage of them too.
      [ Used this_cpu_*() over __get_cpu_var() as suggested by H. Peter Anvin ]
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
  26. 14 May, 2012 1 commit
  27. 16 Apr, 2012 1 commit
  28. 23 Mar, 2012 1 commit
  29. 28 Feb, 2012 1 commit
    • Paul Gortmaker's avatar
      x86: relocate get/set debugreg fcns to include/asm/debugreg. · f649e938
      Paul Gortmaker authored
      Since we already have a debugreg.h header file, move the
      assoc. get/set functions to it.  In addition to it being the
      logical home for them, it has a secondary advantage.  The
      functions that are moved use BUG().  So we really need to
      have linux/bug.h in scope.  But asm/processor.h is used about
      600 times, vs. only about 15 for debugreg.h -- so adding bug.h
      to the latter reduces the amount of time we'll be processing
      it during a compile.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      CC: Thomas Gleixner <tglx@linutronix.de>
      CC: "H. Peter Anvin" <hpa@zytor.com>
  30. 21 Feb, 2012 1 commit
    • Linus Torvalds's avatar
      i387: Split up <asm/i387.h> into exported and internal interfaces · 1361b83a
      Linus Torvalds authored
      While various modules include <asm/i387.h> to get access to things we
      actually *intend* for them to use, most of that header file was really
      pretty low-level internal stuff that we really don't want to expose to
      So split the header file into two: the small exported interfaces remain
      in <asm/i387.h>, while the internal definitions that are only used by
      core architecture code are now in <asm/fpu-internal.h>.
      The guiding principle for this was to expose functions that we export to
      modules, and leave them in <asm/i387.h>, while stuff that is used by
      task switching or was marked GPL-only is in <asm/fpu-internal.h>.
      The fpu-internal.h file could be further split up too, especially since
      arch/x86/kvm/ uses some of the remaining stuff for its module.  But that
      kvm usage should probably be abstracted out a bit, and at least now the
      internal FPU accessor functions are much more contained.  Even if it
      isn't perhaps as contained as it _could_ be.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1202211340330.5354@i5.linux-foundation.org
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>