1. 19 6月, 2015 4 次提交
    • P
      perf/x86: Honor the architectural performance monitoring version · 2c33645d
      Palik, Imre 提交于
      Architectural performance monitoring, version 1, doesn't support fixed counters.
      
      Currently, even if a hypervisor advertises support for architectural
      performance monitoring version 1, perf may still try to use the fixed
      counters, as the constraints are set up based on the CPU model.
      
      This patch ensures that perf honors the architectural performance monitoring
      version returned by CPUID, and it only uses the fixed counters for version 2
      and above.
      
      (Some of the ideas in this patch came from Peter Zijlstra.)
      Signed-off-by: NImre Palik <imrep@amazon.de>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Anthony Liguori <aliguori@amazon.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1433767609-1039-1-git-send-email-imrep.amz@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2c33645d
    • A
      perf/x86/intel: Fix PMI handling for Intel PT · 1b7b938f
      Alexander Shishkin 提交于
      Intel PT is a separate PMU and it is not using any of the x86_pmu
      code paths, which means in particular that the active_events counter
      remains intact when new PT events are created.
      
      However, PT uses the generic x86_pmu PMI handler for its PMI handling needs.
      
      The problem here is that the latter checks active_events and in case of it
      being zero, exits without calling the actual x86_pmu.handle_nmi(), which
      results in unknown NMI errors and massive data loss for PT.
      
      The effect is not visible if there are other perf events in the system
      at the same time that keep active_events counter non-zero, for instance
      if the NMI watchdog is running, so one needs to disable it to reproduce
      the problem.
      
      At the same time, the active_events counter besides doing what the name
      suggests also implicitly serves as a PMC hardware and DS area reference
      counter.
      
      This patch adds a separate reference counter for the PMC hardware, leaving
      active_events for actually counting the events and makes sure it also
      counts PT and BTS events.
      Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@infradead.org
      Cc: adrian.hunter@intel.com
      Link: http://lkml.kernel.org/r/87k2v92t0s.fsf@ashishki-desk.ger.corp.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1b7b938f
    • A
      perf/x86/intel/bts: Fix DS area sharing with x86_pmu events · 6b099d9b
      Alexander Shishkin 提交于
      Currently, the intel_bts driver relies on the DS area allocated by the x86_pmu
      code in its event_init() path, which is a bug: creating a BTS event while
      no x86_pmu events are present results in a NULL pointer dereference.
      
      The same DS area is also used by PEBS sampling, which makes it quite a bit
      trickier to have a separate one for intel_bts' purposes.
      
      This patch makes intel_bts driver use the same DS allocation and reference
      counting code as x86_pmu to make sure it is always present when either
      intel_bts or x86_pmu need it.
      Signed-off-by: NAlexander Shishkin <alexander.shishkin@linux.intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@infradead.org
      Cc: adrian.hunter@intel.com
      Link: http://lkml.kernel.org/r/1434024837-9916-2-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6b099d9b
    • A
      perf/x86: Add more Broadwell model numbers · 4b36f1a4
      Andi Kleen 提交于
      This patch adds additional model numbers for Broadwell to perf.
      Support for Broadwell with Iris Pro (Intel Core i7-57xxC)
      and support for Broadwell Server Xeon.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1434055942-28253-1-git-send-email-andi@firstfloor.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      4b36f1a4
  2. 16 6月, 2015 1 次提交
    • R
      KVM: x86: fix lapic.timer_mode on restore · b6ac0695
      Radim Krčmář 提交于
      lapic.timer_mode was not properly initialized after migration, which
      broke few useful things, like login, by making every sleep eternal.
      
      Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore.
      
      There are other slowpaths that update lvtt, so this patch makes sure
      something similar doesn't happen again by calling apic_update_lvtt
      after every modification.
      
      Cc: stable@vger.kernel.org
      Fixes: f30ebc31 ("KVM: x86: optimize some accesses to LVTT and SPIV")
      Signed-off-by: NRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: NMarcelo Tosatti <mtosatti@redhat.com>
      b6ac0695
  3. 11 6月, 2015 3 次提交
    • A
      arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug · 5ec45a19
      Andrew Morton 提交于
      Fix this compile issue with gcc-4.4.4:
      
         arch/x86/kvm/mmu.c: In function 'kvm_mmu_pte_write':
         arch/x86/kvm/mmu.c:4256: error: unknown field 'cr0_wp' specified in initializer
         arch/x86/kvm/mmu.c:4257: error: unknown field 'cr4_pae' specified in initializer
         arch/x86/kvm/mmu.c:4257: warning: excess elements in union initializer
         ...
      
      gcc-4.4.4 (at least) has issues when using anonymous unions in
      initializers.
      
      Fixes: edc90b7d ("KVM: MMU: fix SMAP virtualization")
      Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ec45a19
    • G
      score: Fix exception handler label · 80524e93
      Guenter Roeck 提交于
      The latest version of modinfo fails to compile score architecture
      targets with the following error.
      
      FATAL: The relocation at __ex_table+0x634 references
      section "__ex_table" which is not executable, IOW
      the kernel will fault if it ever tries to
      jump to it.  Something is seriously wrong
      and should be fixed.
      
      The probem is caused by a bad label in an __ex_table entry.
      Acked-by: NLennox Wu <lennox.wu@gmail.com>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      80524e93
    • G
      blackfin: Fix build error · 5eea9003
      Guenter Roeck 提交于
      Fix
      
      include/asm-generic/io.h: In function 'readb':
      include/asm-generic/io.h:113:2: error:
      	implicit declaration of function 'bfin_read8'
      include/asm-generic/io.h: In function 'readw':
      include/asm-generic/io.h:121:2: error:
      	implicit declaration of function 'bfin_read16'
      include/asm-generic/io.h: In function 'readl':
      include/asm-generic/io.h:129:2: error:
      	implicit declaration of function 'bfin_read32'
      include/asm-generic/io.h: In function 'writeb':
      include/asm-generic/io.h:147:2: error:
      	implicit declaration of function 'bfin_write8'
      include/asm-generic/io.h: In function 'writew':
      include/asm-generic/io.h:155:2: error:
      	implicit declaration of function 'bfin_write16'
      include/asm-generic/io.h: In function 'writel':
      include/asm-generic/io.h:163:2: error:
      	implicit declaration of function 'bfin_write32'
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Fixes: 1a3372bc ("blackfin: io: define __raw_readx/writex with
      	bfin_readx/writex")
      Cc: Steven Miao <realmz6@gmail.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      5eea9003
  4. 10 6月, 2015 3 次提交
  5. 09 6月, 2015 2 次提交
    • I
      Revert "perf/x86/intel/uncore: Move uncore_box_init() out of driver initialization" · 15c12479
      Ingo Molnar 提交于
      This reverts commit c05199e5.
      
      Vince Weaver reported the following crash while perf fuzzing:
      
      [   79.473121] kernel BUG at mm/vmalloc.c:1335!
      [   79.694391] Call Trace:
      [   79.696997]  <IRQ>
      [   79.699090]  [<ffffffff811b2130>] get_vm_area_caller+0x40/0x50
      [   79.705505]  [<ffffffff81039f4d>] ? snb_uncore_imc_init_box+0x6d/0x90
      [   79.712414]  [<ffffffff810635e5>] __ioremap_caller+0x195/0x350
      [   79.718610]  [<ffffffff81039f4d>] ? snb_uncore_imc_init_box+0x6d/0x90
      [   79.725462]  [<ffffffff81427f6b>] ? debug_object_activate+0x14b/0x1e0
      [   79.732346]  [<ffffffff810637b7>] ioremap_nocache+0x17/0x20
      [   79.738283]  [<ffffffff81039f4d>] snb_uncore_imc_init_box+0x6d/0x90
      [   79.744945]  [<ffffffff81039cf7>] snb_uncore_imc_event_start+0xb7/0x110
      [   79.752020]  [<ffffffff81039d97>] snb_uncore_imc_event_add+0x47/0x60
      [   79.758832]  [<ffffffff81162cbb>] event_sched_in.isra.85+0xfb/0x330
      [   79.765519]  [<ffffffff81162f5f>] group_sched_in+0x6f/0x1e0
      [   79.771481]  [<ffffffff8101df1a>] ? native_sched_clock+0x2a/0x90
      [   79.777858]  [<ffffffff811637bc>] __perf_event_enable+0x25c/0x2a0
      [   79.784418]  [<ffffffff810f3e69>] ? tick_nohz_irq_exit+0x29/0x30
      [   79.790820]  [<ffffffff8115ef30>] ? cpu_clock_event_start+0x40/0x40
      [   79.797546]  [<ffffffff8115ef80>] remote_function+0x50/0x60
      [   79.803535]  [<ffffffff810f8cd1>] flush_smp_call_function_queue+0x81/0x180
      [   79.810840]  [<ffffffff810f9763>] generic_smp_call_function_single_interrupt+0x13/0x60
      [   79.819328]  [<ffffffff8104b5e8>] smp_trace_call_function_single_interrupt+0x38/0xc0
      [   79.827614]  [<ffffffff816de9be>] trace_call_function_single_interrupt+0x6e/0x80
      [   79.835465]  <EOI>
      [   79.837543]  [<ffffffff8156e8b5>] ? cpuidle_enter_state+0x65/0x160
      [   79.844377]  [<ffffffff8156e8a1>] ? cpuidle_enter_state+0x51/0x160
      [   79.851015]  [<ffffffff8156e9e7>] cpuidle_enter+0x17/0x20
      [   79.856791]  [<ffffffff810b6e39>] cpu_startup_entry+0x399/0x440
      [   79.863165]  [<ffffffff816c9ddb>] rest_init+0xbb/0xd0
      
      The offending commit is clearly confused as it moves heavy initialization
      work into IPI context.
      
      Revert it.
      Reported-by: NVince Weaver <vincent.weaver@maine.edu>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Yan, Zheng <zheng.z.yan@intel.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      15c12479
    • M
      MIPS: pgtable-bits: Fix XPA damage to R6 definitions. · d7b63141
      Markos Chandras 提交于
      Commit be0c37c9 ("MIPS: Rearrange PTE bits into fixed positions.")
      rearranged the PTE bits into fixed positions in preparation for the XPA
      support. However, this patch broke R6 since it only took R2 cores
      into consideration for the RI/XI bits leading to boot failures. We fix
      this by adding the missing CONFIG_CPU_MIPSR6 definitions
      
      Fixes: be0c37c9 ("MIPS: Rearrange PTE bits into fixed positions.")
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10208/Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d7b63141
  6. 07 6月, 2015 11 次提交
  7. 06 6月, 2015 5 次提交
  8. 04 6月, 2015 3 次提交
  9. 03 6月, 2015 2 次提交
  10. 02 6月, 2015 4 次提交
    • A
      MIPS: ath79: Add a missing new line in log message · a26484bb
      Alban Bedel 提交于
      The memory setup log is missing a new line.
      Signed-off-by: NAlban Bedel <albeu@free.fr>
      Cc: linux-mips@linux-mips.org
      Cc: Andrew Bresticker <abrestic@chromium.org>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: Sergey Ryazanov <ryazanov.s.a@gmail.com>
      Cc: Gabor Juhos <juhosg@openwrt.org>
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/9771/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a26484bb
    • A
      x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers · 425be567
      Andy Lutomirski 提交于
      The early_idt_handlers asm code generates an array of entry
      points spaced nine bytes apart.  It's not really clear from that
      code or from the places that reference it what's going on, and
      the code only works in the first place because GAS never
      generates two-byte JMP instructions when jumping to global
      labels.
      
      Clean up the code to generate the correct array stride (member size)
      explicitly. This should be considerably more robust against
      screw-ups, as GAS will warn if a .fill directive has a negative
      count.  Using '. =' to advance would have been even more robust
      (it would generate an actual error if it tried to move
      backwards), but it would pad with nulls, confusing anyone who
      tries to disassemble the code.  The new scheme should be much
      clearer to future readers.
      
      While we're at it, improve the comments and rename the array and
      common code.
      
      Binutils may start relaxing jumps to non-weak labels.  If so,
      this change will fix our build, and we may need to backport this
      change.
      
      Before, on x86_64:
      
        0000000000000000 <early_idt_handlers>:
           0:   6a 00                   pushq  $0x0
           2:   6a 00                   pushq  $0x0
           4:   e9 00 00 00 00          jmpq   9 <early_idt_handlers+0x9>
                                5: R_X86_64_PC32        early_idt_handler-0x4
        ...
          48:   66 90                   xchg   %ax,%ax
          4a:   6a 08                   pushq  $0x8
          4c:   e9 00 00 00 00          jmpq   51 <early_idt_handlers+0x51>
                                4d: R_X86_64_PC32       early_idt_handler-0x4
        ...
         117:   6a 00                   pushq  $0x0
         119:   6a 1f                   pushq  $0x1f
         11b:   e9 00 00 00 00          jmpq   120 <early_idt_handler>
                                11c: R_X86_64_PC32      early_idt_handler-0x4
      
      After:
      
        0000000000000000 <early_idt_handler_array>:
           0:   6a 00                   pushq  $0x0
           2:   6a 00                   pushq  $0x0
           4:   e9 14 01 00 00          jmpq   11d <early_idt_handler_common>
        ...
          48:   6a 08                   pushq  $0x8
          4a:   e9 d1 00 00 00          jmpq   120 <early_idt_handler_common>
          4f:   cc                      int3
          50:   cc                      int3
        ...
         117:   6a 00                   pushq  $0x0
         119:   6a 1f                   pushq  $0x1f
         11b:   eb 03                   jmp    120 <early_idt_handler_common>
         11d:   cc                      int3
         11e:   cc                      int3
         11f:   cc                      int3
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Binutils <binutils@sourceware.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/ac027962af343b0c599cbfcf50b945ad2ef3d7a8.1432336324.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      425be567
    • M
      ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage · 7a6cb0ab
      Matthijs van Duin 提交于
      Avoid entering "RTC-only mode" at poweroff. It is unsupported by most
      versions of BeagleBone, and risks hardware damage.
      
      The damaging configuration is having system-power-controller
      without ti,pmic-shutdown-controller.
      Reported-by: NMatthijs van Duin <matthijsvanduin@gmail.com>
      Tested-by: NMatthijs van Duin <matthijsvanduin@gmail.com>
      Signed-off-by: NRobert Nelson <robertcnelson@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Johan Hovold <johan@kernel.org>
      [Matthijs van Duin: added explanatory comments]
      Signed-off-by: NMatthijs van Duin <matthijsvanduin@gmail.com>
      Fixes: http://bugs.elinux.org/issues/143
      Cc: stable@vger.kernel.org # v3.12+
      [tony@atomide.com: updated comments with the hardware breaking info]
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      7a6cb0ab
    • T
      ARM: dts: AM35xx: fix system control module clocks · b33558c9
      Tero Kristo 提交于
      New system control module layout for omap3 overlooked parts of the am35xx
      configuration. Basically the am35xx clocks were not converted to use the
      changed offsets, which caused weird boot warnings. The errors were not
      fatal so far, so they were not caught earlier. Fixed by applying the
      proper offsets for the AM35xx scm clocks.
      
      Fixes: b8845074 ("ARM: dts: omap3: add minimal l4 bus layout with...")
      Signed-off-by: NTero Kristo <t-kristo@ti.com>
      Reported-by: NJeroen Hofstee <linux-arm@myspectrum.nl>
      Cc: Paul Walmsley <paul@pwsan.com>
      Tested-by: NJeroen Hofstee <jeroen@myspectrum.nl>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      b33558c9
  11. 01 6月, 2015 2 次提交