28 Oct, 2011
1 commit
-
* 'x86-rdrand-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, random: Verify RDRAND functionality and allow it to be disabled
x86, random: Architectural inlines to get random integers with RDRAND
random: Add support for architectural random hooksFix up trivial conflicts in drivers/char/random.c: the architectural
random hooks touched "get_random_int()" that was simplified to use MD5
and not do the keyptr thing any more (see commit 6e5714eaf77d: "net:
Compute protocol sequence numbers and fragment IDs using MD5").
10 Oct, 2011
1 commit
-
This patch implements IBS feature detection and initialzation. The
code is shared between perf and oprofile. If IBS is available on the
system for perf, a pmu is setup.Signed-off-by: Robert Richter
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/1316597423-25723-3-git-send-email-robert.richter@amd.com
Signed-off-by: Ingo Molnar
26 Sep, 2011
1 commit
-
The CPU support for perf events on x86 was implemented via included C files
with #ifdefs. Clean this up by creating a new header file and compiling
the vendor-specific files as needed.Signed-off-by: Kevin Winchester
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/1314747665-2090-1-git-send-email-kjwinchester@gmail.com
Signed-off-by: Ingo Molnar
01 Aug, 2011
1 commit
-
If the CPU declares that RDRAND is available, go through a guranteed
reseed sequence, and make sure that it is actually working (producing
data.) If it does not, disable the CPU feature flag.Allow RDRAND to be disabled on the command line (as opposed to at
compile time) for a user who has special requirements with regards to
random numbers.Signed-off-by: H. Peter Anvin
Cc: Matt Mackall
Cc: Herbert Xu
Cc: "Theodore Ts'o"
20 May, 2011
1 commit
-
Signed-off-by: Dave Jones
07 Aug, 2010
1 commit
-
* 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
um, x86: Cast to (u64 *) inside set_64bit()
x86-32, asm: Directly access per-cpu GDT
x86-64, asm: Directly access per-cpu IST
x86, asm: Merge cmpxchg_486_u64() and cmpxchg8b_emu()
x86, asm: Move cmpxchg emulation code to arch/x86/lib
x86, asm: Clean up and simplify
x86, asm: Clean up and simplify set_64bit()
x86: Add memory modify constraints to xchg() and cmpxchg()
x86-64: Simplify loading initial_gs
x86: Use symbolic MSR names
x86: Remove redundant K6 MSRs
29 Jul, 2010
1 commit
-
Move cmpxchg emulation code from arch/x86/kernel/cpu (which is
otherwise CPU identification) to arch/x86/lib, where other emulation
code lives already.Signed-off-by: H. Peter Anvin
LKML-Reference:
20 Jul, 2010
1 commit
-
addon_cpuid_features.c contains exactly two almost completely
unrelated functions, plus has a long and very generic name. Split it
into two files, scattered.c for the scattered feature flags, and
topology.c for the topology information.Signed-off-by: H. Peter Anvin
LKML-Reference:
07 May, 2010
1 commit
-
This patch integrates HyperV detection within the framework currently
used by VmWare. With this patch, we can avoid having to replicate the
HyperV detection code in each of the Microsoft HyperV drivers.Reworked and tweaked by Greg K-H to build properly.
Signed-off-by: K. Y. Srinivasan
LKML-Reference:
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Vadim Rozenfeld
Cc: Avi Kivity
Cc: Gleb Natapov
Cc: Frederic Weisbecker
Cc: Alexey Dobriyan
Cc: "K.Prasad"
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Paul Mackerras
Cc: Alan Cox
Cc: Haiyang Zhang
Cc: Hank Janssen
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: H. Peter Anvin
24 Jan, 2010
1 commit
-
CONFIG_X86_CPU_DEBUG, which provides some parsed versions of the x86
CPU configuration via debugfs, has caused boot failures on real
hardware. The value of this feature has been marginal at best, as all
this information is already available to userspace via generic
interfaces.Causes crashes that have not been fixed + minimal utility -> remove.
See the referenced LKML thread for more information.
Reported-by: Ozan Çağlayan
Signed-off-by: H. Peter Anvin
LKML-Reference:
Cc: Jaswinder Singh Rajput
Cc: Linus Torvalds
Cc: Rafael J. Wysocki
Cc: Yinghai Lu
Cc:
23 Nov, 2009
1 commit
-
Decreases perf overhead when function tracing is enabled,
by about 50%.Cc: Peter Zijlstra
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Arnaldo Carvalho de Melo
Cc: Frederic Weisbecker
LKML-Reference:
Signed-off-by: Ingo Molnar
21 Sep, 2009
1 commit
-
Bye-bye Performance Counters, welcome Performance Events!
In the past few months the perfcounters subsystem has grown out its
initial role of counting hardware events, and has become (and is
becoming) a much broader generic event enumeration, reporting, logging,
monitoring, analysis facility.Naming its core object 'perf_counter' and naming the subsystem
'perfcounters' has become more and more of a misnomer. With pending
code like hw-breakpoints support the 'counter' name is less and
less appropriate.All in one, we've decided to rename the subsystem to 'performance
events' and to propagate this rename through all fields, variables
and API names. (in an ABI compatible fashion)The word 'event' is also a bit shorter than 'counter' - which makes
it slightly more convenient to write/handle as well.Thanks goes to Stephane Eranian who first observed this misnomer and
suggested a rename.User-space tooling and ABI compatibility is not affected - this patch
should be function-invariant. (Also, defconfigs were not touched to
keep the size down.)This patch has been generated via the following script:
FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')
sed -i \
-e 's/PERF_EVENT_/PERF_RECORD_/g' \
-e 's/PERF_COUNTER/PERF_EVENT/g' \
-e 's/perf_counter/perf_event/g' \
-e 's/nb_counters/nb_events/g' \
-e 's/swcounter/swevent/g' \
-e 's/tpcounter_event/tp_event/g' \
$FILESfor N in $(find . -name perf_counter.[ch]); do
M=$(echo $N | sed 's/perf_counter/perf_event/g')
mv $N $M
doneFILES=$(find . -name perf_event.*)
sed -i \
-e 's/COUNTER_MASK/REG_MASK/g' \
-e 's/COUNTER/EVENT/g' \
-e 's/\/event_id/g' \
-e 's/counter/event/g' \
-e 's/Counter/Event/g' \
$FILES... to keep it as correct as possible. This script can also be
used by anyone who has pending perfcounters patches - it converts
a Linux kernel tree over to the new naming. We tried to time this
change to the point in time where the amount of pending patches
is the smallest: the end of the merge window.Namespace clashes were fixed up in a preparatory patch - and some
stylistic fallout will be fixed up in a subsequent patch.( NOTE: 'counters' are still the proper terminology when we deal
with hardware registers - and these sed scripts are a bit
over-eager in renaming them. I've undone some of that, but
in case there's something left where 'counter' would be
better than 'event' we can undo that on an individual basis
instead of touching an otherwise nicely automated patch. )Suggested-by: Stephane Eranian
Acked-by: Peter Zijlstra
Acked-by: Paul Mackerras
Reviewed-by: Arjan van de Ven
Cc: Mike Galbraith
Cc: Arnaldo Carvalho de Melo
Cc: Frederic Weisbecker
Cc: Steven Rostedt
Cc: Benjamin Herrenschmidt
Cc: David Howells
Cc: Kyle McMartin
Cc: Martin Schwidefsky
Cc: "David S. Miller"
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc:
LKML-Reference:
Signed-off-by: Ingo Molnar
15 Sep, 2009
1 commit
-
APERF/MPERF support for cpu_power.
APERF/MPERF is arch defined to be a relative scale of work capacity
per logical cpu, this is assumed to include SMT and Turbo mode.APERF/MPERF are specified to both reset to 0 when either counter
wraps, which is highly inconvenient, since that'll give a blimp
when that happens. The manual specifies writing 0 to the counters
after each read, but that's 1) too expensive, and 2) destroys the
possibility of sharing these counters with other users, so we live
with the blimp - the other existing user does too.Signed-off-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
20 Aug, 2009
2 commits
-
load_percpu_segment() is used to set up the per-cpu segment registers,
which are also used for -fstack-protector. Make sure that the
load_percpu_segment() function doesn't have stackprotector enabled.[ Impact: allow percpu setup before calling stack-protected functions ]
Signed-off-by: Jeremy Fitzhardinge
06 Apr, 2009
1 commit
-
Merge reason: we have gathered quite a few conflicts, need to merge upstream
Conflicts:
arch/powerpc/kernel/Makefile
arch/x86/ia32/ia32entry.S
arch/x86/include/asm/hardirq.h
arch/x86/include/asm/unistd_32.h
arch/x86/include/asm/unistd_64.h
arch/x86/kernel/cpu/common.c
arch/x86/kernel/irq.c
arch/x86/kernel/syscall_table_32.S
arch/x86/mm/iomap_32.c
include/linux/sched.h
kernel/MakefileSigned-off-by: Ingo Molnar
14 Mar, 2009
1 commit
-
there should be no difference, except:
* the 64bit variant now also initializes the padlock unit.
* ->c_early_init() is executed again from ->c_init()
* the 64bit fixups made into 32bit path.Signed-off-by: Sebastian Andrzej Siewior
Cc: herbert@gondor.apana.org.au
LKML-Reference:
Signed-off-by: Ingo Molnar
11 Mar, 2009
1 commit
-
Introduce:
cat /sys/kernel/debug/x86/cpu/*
for Intel and AMD processors to view / debug the state of each CPU.
By using this we can debug whole range of registers and other
cpu information for debugging purpose and monitor how things
are changing.This can be useful for developers as well as for users.
Signed-off-by: Jaswinder Singh Rajput
LKML-Reference:
Signed-off-by: Ingo Molnar
29 Dec, 2008
2 commits
-
Conflicts:
fs/exec.c
include/linux/init_task.hSimple context conflicts.
-
…el/git/tip/linux-2.6-tip
* 'tracing-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (241 commits)
sched, trace: update trace_sched_wakeup()
tracing/ftrace: don't trace on early stage of a secondary cpu boot, v3
Revert "x86: disable X86_PTRACE_BTS"
ring-buffer: prevent false positive warning
ring-buffer: fix dangling commit race
ftrace: enable format arguments checking
x86, bts: memory accounting
x86, bts: add fork and exit handling
ftrace: introduce tracing_reset_online_cpus() helper
tracing: fix warnings in kernel/trace/trace_sched_switch.c
tracing: fix warning in kernel/trace/trace.c
tracing/ring-buffer: remove unused ring_buffer size
trace: fix task state printout
ftrace: add not to regex on filtering functions
trace: better use of stack_trace_enabled for boot up code
trace: add a way to enable or disable the stack tracer
x86: entry_64 - introduce FTRACE_ frame macro v2
tracing/ftrace: add the printk-msg-only option
tracing/ftrace: use preempt_enable_no_resched_notrace in ring_buffer_time_stamp()
x86, bts: correctly report invalid bts records
...Fixed up trivial conflict in scripts/recordmcount.pl due to SH bits
being already partly merged by the SH merge.
25 Dec, 2008
1 commit
-
Impact: fix a crash/hard-reboot on certain configs while enabling cpu runtime
On some archs, the boot of a secondary cpu can have an early fragile state.
On x86-64, the pda is not initialized on the first stage of a cpu boot but
it is needed to get the cpu number and the current task pointer. This data
is needed during tracing. As they were dereferenced at this stage, we got a
crash while tracing a cpu being enabled at runtime.Some other archs like ia64 can have such kind of issue too.
Changes on v2:
We dropped the previous solution of a per-arch called function to guess the
current state of a cpu. That could slow down the tracing.This patch removes the -pg flag on arch/x86/kernel/cpu/common.c where
the low level cpu boot functions exist, on start_secondary() and a helper
function used at this stage.Signed-off-by: Frederic Weisbecker
Acked-by: Steven Rostedt
Signed-off-by: Ingo Molnar
08 Dec, 2008
1 commit
-
Implement performance counters for x86 Intel CPUs.
It's simplified right now: the PERFMON CPU feature is assumed,
which is available in Core2 and later Intel CPUs.The design is flexible to be extended to more CPU types as well.
Signed-off-by: Ingo Molnar
02 Nov, 2008
1 commit
-
Impact: Changes timebase calibration on Vmware.
v3->v2 : Abstract the hypervisor detection and feature (tsc_freq) request
behind a hypervisor.c file
v2->v1 : Add a x86_hyper_vendor field to the cpuinfo_x86 structure.
This avoids multiple calls to the hypervisor detection function.This patch adds function to detect if we are running under VMware.
The current way to check if we are on VMware is following,
# check if "hypervisor present bit" is set, if so read the 0x40000000
cpuid leaf and check for "VMwareVMware" signature.
# if the above fails, check the DMI vendors name for "VMware" string
if we find one we query the VMware hypervisor port to check if we are
under VMware.The DMI + "VMware hypervisor port check" is needed for older VMware products,
which don't implement the hypervisor signature cpuid leaf.
Also note that since we are checking for the DMI signature the hypervisor
port should never be accessed on native hardware.This patch also adds a hypervisor_get_tsc_freq function, instead of
calibrating the frequency which can be error prone in virtualized
environment, we ask the hypervisor for it. We get the frequency from
the hypervisor by accessing the hypervisor port if we are running on VMware.
Other hypervisors too can add code to the generic routine to get frequency on
their platform.Signed-off-by: Alok N Kataria
Signed-off-by: Dan Hecht
Signed-off-by: H. Peter Anvin
23 Oct, 2008
1 commit
-
Signed-off-by: Al Viro
Signed-off-by: H. Peter Anvin
10 Sep, 2008
1 commit
-
now that arch/x86/kernel/cpu/intel_64.c and
arch/x86/kernel/cpu/intel.c are equal, drop
arch/x86/kernel/cpu/intel_64.c and fix up
the glue.Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar
08 Sep, 2008
1 commit
-
arch/x86/kernel/cpu/amd.c is now 100% identical to
arch/x86/kernel/cpu/amd_64.c, so use amd.c on 64-bit too
and fix up the namespace impact.Simplify the Kconfig glue as well.
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar
05 Sep, 2008
2 commits
-
Use cpu/common.c on both 64-bit and 32-bit and remove cpu/common_64.c.
We started out with this linecount:
816 arch/x86/kernel/cpu/common_64.c
805 arch/x86/kernel/cpu/common.cand the resulting common.c is 1197 lines long, so there's already
424 lines of code eliminated in this phase of the unification.Signed-off-by: Yinghai
Signed-off-by: Ingo Molnar -
1. add c_x86_vendor into cpu_dev
2. change cpu_devs to static
3. check c_x86_vendor before put that cpu_dev into array
4. remove alignment for 64bit
5. order the sequence in cpu_devs according to link sequence...
so could put intel at first, then amd...Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar
28 Aug, 2008
1 commit
-
We have had a number of cases where (and its
predecessors) have diverged substantially from the names list in
/proc/cpuinfo. This patch generates the latter from the former.It retains the option for explicitly overriding the strings, but by
making that require a separate action it should at least be less
likely to happen.It would be good to do a future pass and rename strings that are
gratuituously different in the kernel (/proc/cpuinfo is a userspace
interface and must remain constant.)Signed-off-by: H. Peter Anvin
18 Aug, 2008
2 commits
-
This patch adds some configuration options that allow to compile out
CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
new configuration options are only visible when CONFIG_EMBEDDED is
selected, as they are mostly interesting for space savings reasons.An example of size saving, on x86 with only Intel CPU support:
text data bss dec hex filename
1125479 118760 212992 1457231 163c4f vmlinux.old
1121355 116536 212992 1450883 162383 vmlinux
-4124 -2224 0 -6348 -18CC +/-However, I'm not exactly sure that the Kconfig wording is correct with
regard to !64BIT / 64BIT.[ mingo@elte.hu: convert macro to inline ]
Signed-off-by: Thomas Petazzoni
Signed-off-by: Ingo Molnar -
arch/x86/kernel/cpu/intel.c defines a few fallback functions
(cmpxchg_*()) that are used when the CPU doesn't support cmpxchg
and/or cmpxchg64 natively. However, while defined in an Intel-specific
file, these functions are also used for CPUs from other vendors when
they don't support cmpxchg and/or cmpxchg64. This breaks the
compilation when support for Intel CPUs is disabled.This patch moves these functions to a new
arch/x86/kernel/cpu/cmpxchg.c file, unconditionally compiled when
X86_32 is enabled.Signed-off-by: Thomas Petazzoni
Cc: michael@free-electrons.com
Signed-off-by: Ingo Molnar
08 Jul, 2008
1 commit
-
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar
04 Jun, 2008
1 commit
-
It looks good to move bugs_64.c to cpu/bugs_64.c.
Signed-off-by: Hiroshi Shimamoto
Signed-off-by: H. Peter Anvin
31 May, 2008
3 commits
-
Create a separate centaur_64.c file in the cpu/ dir for
the useful parts to live in.Signed-off-by: Dave Jones
Signed-off-by: H. Peter Anvin -
Create a separate intel_64.c file in the cpu/ dir for
the useful parts to live in.Signed-off-by: Dave Jones
Signed-off-by: H. Peter Anvin -
Create a separate amd_64.c file in the cpu/ dir for
the useful parts to live in.Signed-off-by: Dave Jones
Signed-off-by: H. Peter Anvin
26 Apr, 2008
1 commit
-
It is claimed that NexGen CPUs were never shipped:
http://lkml.org/lkml/2008/4/20/179
Also, the kernel support for these chips has been broken for
a long time, the code intended to support NexGen thereby being
essentially dead.As an outcome of the discussion that can be found using the URL
above, this patch removes the NexGen support altogether.The changes in this patch survived a defconfig build for i386, a
couple of successful randconfig builds, as well as a runtime test,
which consisted in booting a 32-bit x86 box up to the shell prompt.Signed-off-by: Dmitri Vorobiev
Signed-off-by: Ingo Molnar
17 Apr, 2008
2 commits
-
Now cpu/proc.c and cpu/proc_64.c are same.
So cpu/proc_64.c can be removed.Signed-off-by: Hiroshi Shimamoto
Signed-off-by: Ingo Molnar -
x86 /proc/cpuinfo code can be unified.
This is the first step of unification.Signed-off-by: Hiroshi Shimamoto
Signed-off-by: Ingo Molnar
04 Feb, 2008
1 commit
-
Move the CPU feature string names to a separate file (common to 32
and 64 bits); additionally, make includable by host
code in preparation for including the CPU feature strings in the boot
code.Signed-off-by: H. Peter Anvin
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner