1. 13 4月, 2016 16 次提交
  2. 01 4月, 2016 1 次提交
  3. 31 3月, 2016 10 次提交
  4. 29 3月, 2016 13 次提交
    • B
      x86/cpu: Do the feature test first in enable_sep_cpu() · b3edfda4
      Borislav Petkov 提交于
      ... before assigning local vars. Kill out label too and simplify.
      
      No functionality change.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1458130769-24963-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b3edfda4
    • H
      x86/build: Build compressed x86 kernels as PIE · 6d92bc9d
      H.J. Lu 提交于
      The 32-bit x86 assembler in binutils 2.26 will generate R_386_GOT32X
      relocation to get the symbol address in PIC.  When the compressed x86
      kernel isn't built as PIC, the linker optimizes R_386_GOT32X relocations
      to their fixed symbol addresses.  However, when the compressed x86
      kernel is loaded at a different address, it leads to the following
      load failure:
      
        Failed to allocate space for phdrs
      
      during the decompression stage.
      
      If the compressed x86 kernel is relocatable at run-time, it should be
      compiled with -fPIE, instead of -fPIC, if possible and should be built as
      Position Independent Executable (PIE) so that linker won't optimize
      R_386_GOT32X relocation to its fixed symbol address.
      
      Older linkers generate R_386_32 relocations against locally defined
      symbols, _bss, _ebss, _got and _egot, in PIE.  It isn't wrong, just less
      optimal than R_386_RELATIVE.  But the x86 kernel fails to properly handle
      R_386_32 relocations when relocating the kernel.  To generate
      R_386_RELATIVE relocations, we mark _bss, _ebss, _got and _egot as
      hidden in both 32-bit and 64-bit x86 kernels.
      
      To build a 64-bit compressed x86 kernel as PIE, we need to disable the
      relocation overflow check to avoid relocation overflow errors. We do
      this with a new linker command-line option, -z noreloc-overflow, which
      got added recently:
      
       commit 4c10bbaa0912742322f10d9d5bb630ba4e15dfa7
       Author: H.J. Lu <hjl.tools@gmail.com>
       Date:   Tue Mar 15 11:07:06 2016 -0700
      
          Add -z noreloc-overflow option to x86-64 ld
      
          Add -z noreloc-overflow command-line option to the x86-64 ELF linker to
          disable relocation overflow check.  This can be used to avoid relocation
          overflow check if there will be no dynamic relocation overflow at
          run-time.
      
      The 64-bit compressed x86 kernel is built as PIE only if the linker supports
      -z noreloc-overflow.  So far 64-bit relocatable compressed x86 kernel
      boots fine even when it is built as a normal executable.
      Signed-off-by: NH.J. Lu <hjl.tools@gmail.com>
      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: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      [ Edited the changelog and comments. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      6d92bc9d
    • T
      x86/xen, pat: Remove PAT table init code from Xen · 88ba2811
      Toshi Kani 提交于
      Xen supports PAT without MTRRs for its guests.  In order to
      enable WC attribute, it was necessary for xen_start_kernel()
      to call pat_init_cache_modes() to update PAT table before
      starting guest kernel.
      
      Now that the kernel initializes PAT table to the BIOS handoff
      state when MTRR is disabled, this Xen-specific PAT init code
      is no longer necessary.  Delete it from xen_start_kernel().
      
      Also change __init_cache_modes() to a static function since
      PAT table should not be tweaked by other modules.
      Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: elliott@hpe.com
      Cc: paul.gortmaker@windriver.com
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1458769323-24491-7-git-send-email-toshi.kani@hpe.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      88ba2811
    • T
      x86/mtrr: Fix PAT init handling when MTRR is disabled · ad025a73
      Toshi Kani 提交于
      get_mtrr_state() calls pat_init() on BSP even if MTRR is disabled.
      This results in calling pat_init() on BSP only since APs do not call
      pat_init() when MTRR is disabled.  This inconsistency between BSP
      and APs leads to undefined behavior.
      
      Make BSP's calling condition to pat_init() consistent with AP's,
      mtrr_ap_init() and mtrr_aps_init().
      Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: elliott@hpe.com
      Cc: konrad.wilk@oracle.com
      Cc: paul.gortmaker@windriver.com
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1458769323-24491-6-git-send-email-toshi.kani@hpe.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      ad025a73
    • T
      x86/mtrr: Fix Xorg crashes in Qemu sessions · edfe63ec
      Toshi Kani 提交于
      A Xorg failure on qemu32 was reported as a regression [1] caused by
      commit 9cd25aac ("x86/mm/pat: Emulate PAT when it is disabled").
      
      This patch fixes the Xorg crash.
      
      Negative effects of this regression were the following two failures [2]
      in Xorg on QEMU with QEMU CPU model "qemu32" (-cpu qemu32), which were
      triggered by the fact that its virtual CPU does not support MTRRs.
      
       #1. copy_process() failed in the check in reserve_pfn_range()
      
          copy_process
           copy_mm
            dup_mm
             dup_mmap
              copy_page_range
               track_pfn_copy
                reserve_pfn_range
      
       A WC map request was tracked as WC in memtype, which set a PTE as
       UC (pgprot) per __cachemode2pte_tbl[].  This led to this error in
       reserve_pfn_range() called from track_pfn_copy(), which obtained
       a pgprot from a PTE.  It converts pgprot to page_cache_mode, which
       does not necessarily result in the original page_cache_mode since
       __cachemode2pte_tbl[] redirects multiple types to UC.
      
       #2. error path in copy_process() then hit WARN_ON_ONCE in
           untrack_pfn().
      
           x86/PAT: Xorg:509 map pfn expected mapping type uncached-
           minus for [mem 0xfd000000-0xfdffffff], got write-combining
            Call Trace:
           dump_stack
           warn_slowpath_common
           ? untrack_pfn
           ? untrack_pfn
           warn_slowpath_null
           untrack_pfn
           ? __kunmap_atomic
           unmap_single_vma
           ? pagevec_move_tail_fn
           unmap_vmas
           exit_mmap
           mmput
           copy_process.part.47
           _do_fork
           SyS_clone
           do_syscall_32_irqs_on
           entry_INT80_32
      
      These negative effects are caused by two separate bugs, but they
      can be addressed in separate patches.  Fixing the pat_init() issue
      described below addresses the root cause, and avoids Xorg to hit
      these cases.
      
      When the CPU does not support MTRRs, MTRR does not call pat_init(),
      which leaves PAT enabled without initializing PAT.  This pat_init()
      issue is a long-standing issue, but manifested as issue #1 (and then
      hit issue #2) with the above-mentioned commit because the memtype
      now tracks cache attribute with 'page_cache_mode'.
      
      This pat_init() issue existed before the commit, but we used pgprot
      in memtype.  Hence, we did not have issue #1 before.  But WC request
      resulted in WT in effect because WC pgrot is actually WT when PAT
      is not initialized.  This is not how it was designed to work.  When
      PAT is set to disable properly, WC is converted to UC.  The use of
      WT can result in a system crash if the target range does not support
      WT.  Fortunately, nobody ran into such issue before.
      
      To fix this pat_init() issue, PAT code has been enhanced to provide
      pat_disable() interface.  Call this interface when MTRRs are disabled.
      By setting PAT to disable properly, PAT bypasses the memtype check,
      and avoids issue #1.
      
        [1]: https://lkml.org/lkml/2016/3/3/828
        [2]: https://lkml.org/lkml/2016/3/4/775Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: elliott@hpe.com
      Cc: konrad.wilk@oracle.com
      Cc: paul.gortmaker@windriver.com
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1458769323-24491-5-git-send-email-toshi.kani@hpe.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      edfe63ec
    • T
      x86/mm/pat: Replace cpu_has_pat with boot_cpu_has() · d63dcf49
      Toshi Kani 提交于
      Borislav Petkov suggested:
      
       > Please use on init paths boot_cpu_has(X86_FEATURE_PAT) and on fast
       > paths static_cpu_has(X86_FEATURE_PAT). No more of that cpu_has_XXX
       > ugliness.
      
      Replace the use of cpu_has_pat on init paths with boot_cpu_has().
      Suggested-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      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: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Elliott <elliott@hpe.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: konrad.wilk@oracle.com
      Cc: paul.gortmaker@windriver.com
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1458769323-24491-4-git-send-email-toshi.kani@hpe.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d63dcf49
    • T
      x86/mm/pat: Add pat_disable() interface · 224bb1e5
      Toshi Kani 提交于
      In preparation for fixing a regression caused by:
      
        9cd25aac ("x86/mm/pat: Emulate PAT when it is disabled")
      
      ... PAT needs to provide an interface that prevents the OS from
      initializing the PAT MSR.
      
      PAT MSR initialization must be done on all CPUs using the specific
      sequence of operations defined in the Intel SDM.  This requires MTRRs
      to be enabled since pat_init() is called as part of MTRR init
      from mtrr_rendezvous_handler().
      
      Make pat_disable() as the interface that prevents the OS from
      initializing the PAT MSR.  MTRR will call this interface when it
      cannot provide the SDM-defined sequence to initialize PAT.
      
      This also assures that pat_disable() called from pat_bsp_init()
      will set the PAT table properly when CPU does not support PAT.
      Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Elliott <elliott@hpe.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: konrad.wilk@oracle.com
      Cc: paul.gortmaker@windriver.com
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1458769323-24491-3-git-send-email-toshi.kani@hpe.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      224bb1e5
    • T
      x86/mm/pat: Add support of non-default PAT MSR setting · 02f037d6
      Toshi Kani 提交于
      In preparation for fixing a regression caused by:
      
        9cd25aac ("x86/mm/pat: Emulate PAT when it is disabled")'
      
      ... PAT needs to support a case that PAT MSR is initialized with a
      non-default value.
      
      When pat_init() is called and PAT is disabled, it initializes the
      PAT table with the BIOS default value. Xen, however, sets PAT MSR
      with a non-default value to enable WC. This causes inconsistency
      between the PAT table and PAT MSR when PAT is set to disable on Xen.
      
      Change pat_init() to handle the PAT disable cases properly.  Add
      init_cache_modes() to handle two cases when PAT is set to disable.
      
       1. CPU supports PAT: Set PAT table to be consistent with PAT MSR.
       2. CPU does not support PAT: Set PAT table to be consistent with
          PWT and PCD bits in a PTE.
      
      Note, __init_cache_modes(), renamed from pat_init_cache_modes(),
      will be changed to a static function in a later patch.
      Signed-off-by: NToshi Kani <toshi.kani@hpe.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Luis R. Rodriguez <mcgrof@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: elliott@hpe.com
      Cc: konrad.wilk@oracle.com
      Cc: paul.gortmaker@windriver.com
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/1458769323-24491-2-git-send-email-toshi.kani@hpe.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      02f037d6
    • H
      x86/cpu: Add advanced power management bits · 34a4cceb
      Huang Rui 提交于
      Bit 11 of CPUID 8000_0007 edx is processor feedback interface.
      Bit 12 of CPUID 8000_0007 edx is accumulated power.
      
      Print proper names in proc/cpuinfo
      Reported-and-tested-by: NBorislav Petkov <bp@alien8.de>
      Signed-off-by: NHuang Rui <ray.huang@amd.com>
      Cc: Tony Li <tony.li@amd.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Sherry Hurwitz <sherry.hurwitz@amd.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: "Len Brown" <lenb@kernel.org>
      Link: http://lkml.kernel.org/r/1458871720-3209-1-git-send-email-ray.huang@amd.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      34a4cceb
    • B
      x86/thread_info: Merge two !__ASSEMBLY__ sections · 5f870a3f
      Borislav Petkov 提交于
      We have
      
        #ifndef __ASSEMBLY__
        ...
        #endif
      
        #ifndef __ASSEMBLY__
        ...
        #endif
      
      Merge the two.
      
      No functionality change.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Link: http://lkml.kernel.org/r/1459189217-25532-1-git-send-email-bp@alien8.deSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      5f870a3f
    • V
      x86/cpufreq: Remove duplicated TDP MSR macro definitions · 4a6772f5
      Vladimir Zapolskiy 提交于
      The list of CPU model specific registers contains two copies of TDP
      registers, remove the one, which is out of numerical order in the
      list.
      
      Fixes: 6a35fc2d ("cpufreq: intel_pstate: get P1 from TAR when available")
      Signed-off-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Kristen Carlson
       Accardi <kristen@linux.intel.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Link: http://lkml.kernel.org/r/1459018020-24577-1-git-send-email-vladimir_zapolskiy@mentor.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      4a6772f5
    • B
      8196dab4
    • P
      perf/x86/amd: Cleanup Fam10h NB event constraints · 32b62f44
      Peter Zijlstra 提交于
      Avoid allocating the AMD NB event constraints data structure when not
      needed. This gets rid of x86_max_cores usage and avoids allocating
      this on AMD Core Perfctr supporting hardware (which has separate MSRs
      for NB events).
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: aherrmann@suse.com
      Cc: Rui Huang <ray.huang@amd.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: jencce.kernel@gmail.com
      Link: http://lkml.kernel.org/r/20160320124629.GY6375@twins.programming.kicks-ass.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      32b62f44