linux-stable.git/arch/x86/kernel/cpu, branch linux-3.7.y

x86: Hyper-V: register clocksource only if its advertised

2013-02-27T17:20:55+00:00

commit 32068f6527b8f1822a30671dedaf59c567325026 upstream.

Enable hyperv_clocksource only if its advertised as a feature.
XenServer 6 returns the signature which is checked in
ms_hyperv_platform(), but it does not offer all features. Currently the
clocksource is enabled unconditionally in ms_hyperv_init_platform(), and
the result is a hanging guest.

Hyper-V spec Bit 1 indicates the availability of Partition Reference
Counter.  Register the clocksource only if this bit is set.

The guest in question prints this in dmesg:
 [    0.000000] Hypervisor detected: Microsoft HyperV
 [    0.000000] HyperV: features 0x70, hints 0x0

This bug can be reproduced easily be setting 'viridian=1' in a HVM domU
.cfg file. A workaround without this patch is to boot the HVM guest with
'clocksource=jiffies'.

Signed-off-by: Olaf Hering 
Link: http://lkml.kernel.org/r/1359940959-32168-1-git-send-email-kys@microsoft.com
Signed-off-by: K. Y. Srinivasan 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

perf x86: revert 20b279 - require exclude_guest to use PEBS - kernel side

2013-01-28T04:49:00+00:00

commit a706d965dcfdff73bf2bad1c300f8119900714c7 upstream.

This patch is brought to you by the letter 'H'.

Commit 20b279 breaks compatiblity with older perf binaries when run with
precise modifier (:p or :pp) by requiring the exclude_guest attribute to be
set. Older binaries default exclude_guest to 0 (ie., wanting guest-based
samples) unless host only profiling is requested (:H modifier). The workaround
for older binaries is to add H to the modifier list (e.g., -e cycles:ppH -
toggles exclude_guest to 1). This was deemed unacceptable by Linus:

https://lkml.org/lkml/2012/12/12/570

Between family in town and the fresh snow in Breckenridge there is no time left
to be working on the proper fix for this over the holidays. In the New Year I
have more pressing problems to resolve -- like some memory leaks in perf which
are proving to be elusive -- although the aforementioned snow is probably why
they are proving to be elusive. Either way I do not have any spare time to work
on this and from the time I have managed to spend on it the solution is more
difficult than just moving to a new exclude_guest flag (does not work) or
flipping the logic to include_guest (which is not as trivial as one would
think).

So, two options: silently force exclude_guest on as suggested by Gleb which
means no impact to older perf binaries or revert the original patch which
caused the breakage.

This patch does the latter -- reverts the original patch that introduced the
regression. The problem can be revisited in the future as time allows.

Signed-off-by: David Ahern 
Cc: Avi Kivity 
Cc: Gleb Natapov 
Cc: Ingo Molnar 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Robert Richter 
Link: http://lkml.kernel.org/r/1356749767-17322-1-git-send-email-dsahern@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'please-pull-tangchen' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/urgent

2012-11-13T18:01:01+00:00

Pull MCE fix from Tony Luck:

   "Fix problem in CMCI rediscovery code that was illegally
    migrating worker threads to other cpus."

Signed-off-by: Ingo Molnar

x86, amd: Disable way access filter on Piledriver CPUs

2012-10-31T20:06:55+00:00

The Way Access Filter in recent AMD CPUs may hurt the performance of
some workloads, caused by aliasing issues in the L1 cache.
This patch disables it on the affected CPUs.

The issue is similar to that one of last year:
http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00041.html
This new patch does not replace the old one, we just need another
quirk for newer CPUs.

The performance penalty without the patch depends on the
circumstances, but is a bit less than the last year's 3%.

The workloads affected would be those that access code from the same
physical page under different virtual addresses, so different
processes using the same libraries with ASLR or multiple instances of
PIE-binaries. The code needs to be accessed simultaneously from both
cores of the same compute unit.

More details can be found here:
http://developer.amd.com/Assets/SharedL1InstructionCacheonAMD15hCPU.pdf

CPUs affected are anything with the core known as Piledriver.
That includes the new parts of the AMD A-Series (aka Trinity) and the
just released new CPUs of the FX-Series (aka Vishera).
The model numbering is a bit odd here: FX CPUs have model 2,
A-Series has model 10h, with possible extensions to 1Fh. Hence the
range of model ids.

Signed-off-by: Andre Przywara 
Link: http://lkml.kernel.org/r/1351700450-9277-1-git-send-email-osp@andrep.de
Signed-off-by: H. Peter Anvin

x86/mce: Do not change worker's running cpu in cmci_rediscover().

2012-10-30T21:38:12+00:00

cmci_rediscover() used set_cpus_allowed_ptr() to change the current process's
running cpu, and migrate itself to the dest cpu. But worker processes are not
allowed to be migrated. If current is a worker, the worker will be migrated to
another cpu, but the corresponding  worker_pool is still on the original cpu.

In this case, the following BUG_ON in try_to_wake_up_local() will be triggered:
BUG_ON(rq != this_rq());

This will cause the kernel panic. The call trace is like the following:

[ 6155.451107] ------------[ cut here ]------------
[ 6155.452019] kernel BUG at kernel/sched/core.c:1654!
......
[ 6155.452019] RIP: 0010:[]  [] try_to_wake_up_local+0x115/0x130
......
[ 6155.452019] Call Trace:
[ 6155.452019]  [] __schedule+0x764/0x880
[ 6155.452019]  [] schedule+0x29/0x70
[ 6155.452019]  [] schedule_timeout+0x235/0x2d0
[ 6155.452019]  [] ? mark_held_locks+0x8d/0x140
[ 6155.452019]  [] ? __lock_release+0x133/0x1a0
[ 6155.452019]  [] ? _raw_spin_unlock_irq+0x30/0x50
[ 6155.452019]  [] ? trace_hardirqs_on_caller+0x105/0x190
[ 6155.452019]  [] wait_for_common+0x12b/0x180
[ 6155.452019]  [] ? try_to_wake_up+0x2f0/0x2f0
[ 6155.452019]  [] wait_for_completion+0x1d/0x20
[ 6155.452019]  [] stop_one_cpu+0x8a/0xc0
[ 6155.452019]  [] ? __migrate_task+0x1a0/0x1a0
[ 6155.452019]  [] ? complete+0x28/0x60
[ 6155.452019]  [] set_cpus_allowed_ptr+0x128/0x130
[ 6155.452019]  [] cmci_rediscover+0xf5/0x140
[ 6155.452019]  [] mce_cpu_callback+0x18d/0x19d
[ 6155.452019]  [] notifier_call_chain+0x67/0x150
[ 6155.452019]  [] __raw_notifier_call_chain+0xe/0x10
[ 6155.452019]  [] __cpu_notify+0x20/0x40
[ 6155.452019]  [] cpu_notify_nofail+0x15/0x30
[ 6155.452019]  [] _cpu_down+0x262/0x2e0
[ 6155.452019]  [] cpu_down+0x36/0x50
[ 6155.452019]  [] acpi_processor_remove+0x50/0x11e
[ 6155.452019]  [] acpi_device_remove+0x90/0xb2
[ 6155.452019]  [] __device_release_driver+0x7c/0xf0
[ 6155.452019]  [] device_release_driver+0x2f/0x50
[ 6155.452019]  [] acpi_bus_remove+0x32/0x6d
[ 6155.452019]  [] acpi_bus_trim+0x87/0xee
[ 6155.452019]  [] acpi_bus_hot_remove_device+0x88/0x16b
[ 6155.452019]  [] acpi_os_execute_deferred+0x27/0x34
[ 6155.452019]  [] process_one_work+0x219/0x680
[ 6155.452019]  [] ? process_one_work+0x1b8/0x680
[ 6155.452019]  [] ? acpi_os_wait_events_complete+0x23/0x23
[ 6155.452019]  [] worker_thread+0x12e/0x320
[ 6155.452019]  [] ? manage_workers+0x110/0x110
[ 6155.452019]  [] kthread+0xc6/0xd0
[ 6155.452019]  [] kernel_thread_helper+0x4/0x10
[ 6155.452019]  [] ? retint_restore_args+0x13/0x13
[ 6155.452019]  [] ? __init_kthread_worker+0x70/0x70
[ 6155.452019]  [] ? gs_change+0x13/0x13

This patch removes the set_cpus_allowed_ptr() call, and put the cmci rediscover
jobs onto all the other cpus using system_wq. This could bring some delay for
the jobs.

Signed-off-by: Tang Chen 
Signed-off-by: Miao Xie 
Signed-off-by: Tony Luck

x86, AMD: Change Boris' email address

2012-10-30T09:05:50+00:00

Move to private email and put in maintained status.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1351532410-4887-1-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar

perf/x86: Remove unused variable in nhmex_rbox_alter_er()

2012-10-24T10:51:40+00:00

The variable port is initialized but never used
otherwise, so remove the unused variable.

dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)

Signed-off-by: Wei Yongjun 
Cc: Yan, Zheng 
Cc: a.p.zijlstra@chello.nl
Cc: paulus@samba.org
Cc: acme@ghostprotocols.net
Link: http://lkml.kernel.org/r/CAPgLHd8NZkYSkZm22FpZxiEh6HcA0q-V%3D29vdnheiDhgrJZ%2Byw@mail.gmail.com
Signed-off-by: Ingo Molnar

perf/x86: Enable overflow on Intel KNC with a custom knc_pmu_handle_irq()

2012-10-24T10:00:49+00:00

Although based on the Intel P6 design, the interrupt mechnanism
for KNC more closely resembles the Intel architectural
perfmon one.

We can't just re-use that code though, because KNC has different
MSR numbers for the status and ack registers.

In this case we just cut-and paste from perf_event_intel.c
with some minor changes, as it looks like it would not be
worth the trouble to change that code to be MSR-configurable.

Signed-off-by: Vince Weaver 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: eranian@gmail.com
Cc: Meadows Lawrence F 
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1210171304410.23243@vincent-weaver-1.um.maine.edu
[ Small stylistic edits. ]
Signed-off-by: Ingo Molnar

perf/x86: Remove cpuc->enable check on Intl KNC event enable/disable

2012-10-24T10:00:49+00:00

x86_pmu.enable() is called from x86_pmu_enable() with
cpuc->enabled set to 0.  This means we weren't re-enabling the
counters after a context switch.

This patch just removes the check, as it should't be necessary
(and the equivelent x86_ generic code does not have the checks).

The origin of this problem is the KNC driver being based on the
P6 one.   The P6 driver also has this issue, but works anyway
due to various lucky accidents.

Signed-off-by: Vince Weaver 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: eranian@gmail.com
Cc: Meadows
Cc: Lawrence F 
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1210171303290.23243@vincent-weaver-1.um.maine.edu
Signed-off-by: Ingo Molnar

perf/x86: Make Intel KNC use full 40-bit width of counters

2012-10-24T10:00:48+00:00

Early versions of Intel KNC chips have a bug where bits above 32
were not properly set.  We worked around this by only using the
bottom 32 bits (out of 40 that should be available).

It turns out this workaround breaks overflow handling.

The buggy silicon will in theory never be used in production
systems, so remove this workaround so we get proper overflow
support.

Signed-off-by: Vince Weaver 
Cc: Peter Zijlstra 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: eranian@gmail.com
Cc: Meadows Lawrence F 
Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1210171302140.23243@vincent-weaver-1.um.maine.edu
Signed-off-by: Ingo Molnar