linux.git/arch/x86/kernel/cpu/intel.c, branch v2.6.26

x86: clean up cpu capabilities in arch/x86/kernel/cpu/intel.c

2008-04-17T15:40:51+00:00

Signed-off-by: Ingo Molnar

x86: coding style fixes to arch/x86/kernel/cpu/intel.c

2008-04-17T15:40:49+00:00

Before:
   total: 37 errors, 16 warnings, 366 lines checked
After:
   total: 0 errors, 15 warnings, 369 lines checked

No code changed:

arch/x86/kernel/cpu/intel.o:

   text	   data	    bss	    dec	    hex	filename
   1534	    452	      0	   1986	    7c2	intel.o.before
   1534	    452	      0	   1986	    7c2	intel.o.after

md5:
   1ca348a06de6eb354c4b6ea715a57db5  intel.o.before.asm
   1ca348a06de6eb354c4b6ea715a57db5  intel.o.after.asm

Signed-off-by: Paolo Ciarrocchi 
Signed-off-by: Ingo Molnar

x86: use ELF section to list CPU vendor specific code

2008-04-17T15:40:47+00:00

Replace the hardcoded list of initialization functions for each CPU
vendor by a list in an ELF section, which is read at initialization in
arch/x86/kernel/cpu/cpu.c to fill the cpu_devs[] array. The ELF
section, named .x86cpuvendor.init, is reclaimed after boot, and
contains entries of type "struct cpu_vendor_dev" which associates a
vendor number with a pointer to a "struct cpu_dev" structure.

This first modification allows to remove all the VENDOR_init_cpu()
functions.

This patch also removes the hardcoded calls to early_init_amd() and
early_init_intel(). Instead, we add a "c_early_init" member to the
cpu_dev structure, which is then called if not NULL by the generic CPU
initialization code. Unfortunately, in early_cpu_detect(), this_cpu is
not yet set, so we have to use the cpu_devs[] array directly.

This patch is part of the Linux Tiny project, and is needed for
further patch that will allow to disable compilation of unused CPU
support code.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86: add include to cpu/intel.c

2008-02-04T15:48:04+00:00

Fixes sparse warning:

arch/x86/kernel/cpu/intel.c:48:15: warning: symbol 'ppro_with_ram_bug' was not declared. Should it be static?

Signed-off-by: Harvey Harrison 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86: move MWAIT idle check to generic CPU initialization on 32-bit

2008-01-30T12:33:16+00:00

Previously it was only run for Intel CPUs, but AMD Fam10h implements MWAIT too.

This matches 64bit behaviour.

Signed-off-by: Andi Kleen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86: move X86_FEATURE_CONSTANT_TSC into early cpu feature detection

2008-01-30T12:32:40+00:00

Need this in the next patch in time_init and that happens early.

This includes a minor fix on i386 where early_intel_workarounds()
[which is now called early_init_intel] really executes early as
the comments say.

Signed-off-by: Andi Kleen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86: lfence fix

2008-01-30T12:32:38+00:00

LFENCE is available on XMM2 or higher Intel CPUs - not XMM or higher...

this caused boot failures on XMM1 & !XMM1 capable CPUs.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86: Implement support to synchronize RDTSC with LFENCE on Intel CPUs

2008-01-30T12:32:37+00:00

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: Andi Kleen 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86, ptrace: support for branch trace store(BTS)

2008-01-30T12:31:09+00:00

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: Markus Metzger 
Signed-off-by: Suresh Siddha 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486

2008-01-30T12:30:47+00:00

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: Mathieu Desnoyers 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner