kernel/git/stable/linux.git/include/asm-x86_64/msr.h, branch master

i386/x86_64: move headers to include/asm-x86

2007-10-11T09:20:03+00:00

Move the headers to include/asm-x86 and fixup the header install make rules Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar

i386: Add safe variants of rdmsr_on_cpu and wrmsr_on_cpu

2007-05-08T15:22:01+00:00

Add safe (exception handled) variants of rdmsr_on_cpu and wrmsr_on_cpu. You should use these when the target MSR may not actually exist, as doing so could trigger an exception which the regular functions do not handle. The safe variants are slower, though. The upcoming coretemp hardware monitoring driver will need this. Signed-off-by: Rudolf Marek Cc: Alexey Dobriyan Cc: Dave Jones Signed-off-by: Jean Delvare

[PATCH] x86: Clean up x86 control register and MSR macros (corrected)

2007-05-02T17:27:12+00:00

This patch is based on Rusty's recent cleanup of the EFLAGS-related macros; it extends the same kind of cleanup to control registers and MSRs. It also unifies these between i386 and x86-64; at least with regards to MSRs, the two had definitely gotten out of sync. Signed-off-by: H. Peter Anvin Signed-off-by: Andi Kleen

{rd,wr}msr_on_cpu SMP=n optimization

2007-02-20T19:29:37+00:00

Let's save a few bytes in the CONFIG_SMP=n case. Signed-off-by: Adrian Bunk Signed-off-by: Dave Jones

rdmsr_on_cpu, wrmsr_on_cpu

2007-02-20T19:23:43+00:00

There was OpenVZ specific bug rendering some cpufreq drivers unusable on SMP. In short, when cpufreq code thinks it confined itself to needed cpu by means of set_cpus_allowed() to execute rdmsr, some "virtual cpu" feature can migrate process to anywhere. This triggers bugons and does wrong things in general. This got fixed by introducing rdmsr_on_cpu and wrmsr_on_cpu executing rdmsr and wrmsr on given physical cpu by means of smp_call_function_single(). Dave Jones mentioned cpufreq might be not only user of rdmsr_on_cpu() and wrmsr_on_cpu(), so I'm putting them into arch/{i386,x86_64}/lib/ . Signed-off-by: Alexey Dobriyan Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

Merge ../linus

2006-12-12T22:41:41+00:00

Conflicts: drivers/cpufreq/cpufreq.c

[CPUFREQ] p4-clockmod: fix support for Core

2006-12-12T22:29:04+00:00

Support for Core CPUs was broken in two ways in speedstep-lib: for x86_64, we missed a MSR definition; for both x86_64 and i386, the FSB calculation was wrong by four (it's a quad-pumped bus). Also increase the accuracy of the calculation. Signed-off-by: Dominik Brodowski Signed-off-by: Dave Jones

[PATCH] x86-64: Fix comments for MSR_FS_BASE and MSR_GS_BASE.

2006-12-07T01:14:11+00:00

The comments for MSR_FS_BASE & MSR_GS_BASE were transposed. Signed-off-by: Wink Saville Signed-off-by: Andi Kleen

[PATCH] x86-64: x86-64 add Intel Core related PMU MSRs definitions

2006-12-07T01:14:02+00:00

Add o the x86-64 tree a bunch of MSRs related to performance monitoring for the processors based on Intel Core microarchitecture. It also adds some architectural MSRs for PEBS. A similar patch for i386 will follow. changelog: - add Intel Precise-Event Based sampling (PEBS) related MSR - add Intel Data Save (DS) Area related MSR - add Intel Core microarchitecure performance counter MSRs Signed-off-by: stephane eranian Signed-off-by: Andi Kleen

[CPUFREQ][8/8] acpi-cpufreq: Add support for freq feedback from hardware

2006-10-15T23:57:11+00:00

Enable ondemand governor and acpi-cpufreq to use IA32_APERF and IA32_MPERF MSR to get active frequency feedback for the last sampling interval. This will make ondemand take right frequency decisions when hardware coordination of frequency is going on. Without APERF/MPERF, ondemand can take wrong decision at times due to underlying hardware coordination or TM2. Example: * CPU 0 and CPU 1 are hardware cooridnated. * CPU 1 running at highest frequency. * CPU 0 was running at highest freq. Now ondemand reduces it to some intermediate frequency based on utilization. * Due to underlying hardware coordination with other CPU 1, CPU 0 continues to run at highest frequency (as long as other CPU is at highest). * When ondemand samples CPU 0 again next time, without actual frequency feedback from APERF/MPERF, it will think that previous frequency change was successful and can go to wrong target frequency. This is because it thinks that utilization it has got this sampling interval is when running at intermediate frequency, rather than actual highest frequency. More information about IA32_APERF IA32_MPERF MSR: Refer to IA-32 Intel® Architecture Software Developer's Manual at http://developer.intel.com Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones