1. 30 1月, 2008 3 次提交
    • A
      x86: Implement support to synchronize RDTSC with LFENCE on Intel CPUs · 707fa8ed
      Andi Kleen 提交于
      According to Intel RDTSC can be always synchronized with LFENCE
      on all current CPUs. Implement the necessary CPUID bit for that.
      
      It is unclear yet if that is true for all future CPUs too,
      but if there's another way the kernel can be always updated.
      
      Cc: asit.k.mallick@intel.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      707fa8ed
    • M
      x86, ptrace: support for branch trace store(BTS) · eee3af4a
      Markus Metzger 提交于
      Resend using different mail client
      
      Changes to the last version:
      - split implementation into two layers: ds/bts and ptrace
      - renamed TIF's
      - save/restore ds save area msr in __switch_to_xtra()
      - make block-stepping only look at BTF bit
      Signed-off-by: NMarkus Metzger <markus.t.metzger@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      eee3af4a
    • M
      x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486 · 2c0b8a75
      Mathieu Desnoyers 提交于
      Actually, on 386, cmpxchg and cmpxchg_local fall back on
      cmpxchg_386_u8/16/32: it disables interruptions around non atomic
      updates to mimic the cmpxchg behavior.
      
      The comment:
      /* Poor man's cmpxchg for 386. Unsuitable for SMP */
      
      already present in cmpxchg_386_u32 tells much about how this cmpxchg
      implementation should not be used in a SMP context. However, the cmpxchg_local
      can perfectly use this fallback, since it only needs to be atomic wrt the local
      cpu.
      
      This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
      and cmpxchg64_local on 80386 and 80486.
      
      Q:
      but why is it called cmpxchg_486 when the other functions are called
      
      A:
      Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
      missing both on 386 and 486.
      
      Citing Intel's Instruction set reference:
      
      cmpxchg:
      This instruction is not supported on Intel processors earlier than the
      Intel486 processors.
      
      cmpxchg8b:
      This instruction encoding is not supported on Intel processors earlier
      than the Pentium processors.
      
      Q:
      What's the reason to have cmpxchg64_local on 32 bit architectures?
      Without that need all this would just be a few simple defines.
      
      A:
      cmpxchg64_local on 32 bits architectures takes unsigned long long
      parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
      to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
      to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
      
      Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
      makes sense _not_ to define cmpxchg64 while cmpxchg could still be
      available.
      
      Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
      
      However, cmpxchg64_local will be emulated by disabling interrupts on all
      architectures where it is not supported atomically.
      
      Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
      would make the 386/486 fallbacks ugly, make its design different from
      cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
      be emulated) and require the __cmpxchg_local to be expressed as a macro
      rather than an inline function so the parameters would not be fixed to
      unsigned long long in every case.
      
      So I think cmpxchg64_local makes sense there, but I am open to
      suggestions.
      
      Q:
      Are there any callers?
      
      A:
      I am actually using it in LTTng in my timestamping code. I use it to
      work around CPUs with asynchronous TSCs. I need to update 64 bits
      values atomically on this 32 bits architecture.
      
      Changelog:
      - Ran though checkpatch.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      2c0b8a75
  2. 18 10月, 2007 1 次提交
    • S
      i386: fix section mismatch warning in intel.c · d72b1b4f
      Sam Ravnborg 提交于
      Fix following section mismatch warning:
      WARNING: vmlinux.o(.text+0xc88c): Section mismatch: reference to .init.text:trap_init_f00f_bug (between 'init_intel' and 'cpuid4_cache_lookup')
      
      init_intel are __cpuint where trap_init_f00f_bug is __init.
      Fixed by declaring trap_init_f00f_bug __cpuinit.
      
      Moved the defintion of trap_init_f00f_bug to the sole user in init.c
      so the ugly prototype in intel.c could get killed.
      
      Frank van Maarseveen <frankvm@frankvm.com> supplied the .config used
      to reproduce the warning.
      
      [ tglx: arch/x86 adaptation ]
      
      Cc: Frank van Maarseveen <frankvm@frankvm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      d72b1b4f
  3. 11 10月, 2007 1 次提交
  4. 03 5月, 2007 1 次提交
  5. 07 12月, 2006 3 次提交
  6. 26 9月, 2006 2 次提交
  7. 01 7月, 2006 1 次提交
  8. 27 6月, 2006 1 次提交
  9. 23 3月, 2006 1 次提交
  10. 12 1月, 2006 1 次提交
  11. 15 11月, 2005 1 次提交
  12. 14 11月, 2005 1 次提交
  13. 05 9月, 2005 1 次提交
  14. 08 7月, 2005 1 次提交
  15. 26 6月, 2005 1 次提交
  16. 17 4月, 2005 2 次提交