1. 30 1月, 2016 1 次提交
  2. 12 9月, 2014 1 次提交
    • D
      x86: Introduce disabled-features · 381aa07a
      Dave Hansen 提交于
      I believe the REQUIRED_MASK aproach was taken so that it was
      easier to consult in assembly (arch/x86/kernel/verify_cpu.S).
      DISABLED_MASK does not have the same restriction, but I
      implemented it the same way for consistency.
      
      We have a REQUIRED_MASK... which does two things:
      1. Keeps a list of cpuid bits to check in very early boot and
         refuse to boot if those are not present.
      2. Consulted during cpu_has() checks, which allows us to
         optimize out things at compile-time.  In other words, if we
         *KNOW* we will not boot with the feature off, then we can
         safely assume that it will be present forever.
      
      But, we don't have a similar mechanism for CPU features which
      may be present but that we know we will not use.  We simply
      use our existing mechanisms to repeatedly check the status of
      the bit at runtime (well, the alternatives patching helps here
      but it does not provide compile-time optimization).
      
      Adding a feature to disabled-features.h allows the bit to be
      checked via a new macro: cpu_feature_enabled().  Note that
      for features in DISABLED_MASK, checks with this macro have
      all of the benefits of an #ifdef.  Before, we would have done
      this in a header:
      
      #ifdef CONFIG_X86_INTEL_MPX
      #define cpu_has_mpx cpu_has(X86_FEATURE_MPX)
      #else
      #define cpu_has_mpx 0
      #endif
      
      and this in the code:
      
      	if (cpu_has_mpx)
      		do_some_mpx_thing();
      
      Now, just add your feature to DISABLED_MASK and you can do this
      everywhere, and get the same benefits you would have from
      #ifdefs:
      
      	if (cpu_feature_enabled(X86_FEATURE_MPX))
      		do_some_mpx_thing();
      
      We need a new function and *not* a modification to cpu_has()
      because there are cases where we actually need to check the CPU
      itself, despite what features the kernel supports.  The best
      example of this is a hypervisor which has no control over what
      features its guests are using and where the guest does not depend
      on the host for support.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Link: http://lkml.kernel.org/r/20140911211513.9E35E931@viggo.jf.intel.comAcked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      381aa07a
  3. 03 10月, 2012 1 次提交
  4. 08 2月, 2010 1 次提交
  5. 17 9月, 2008 1 次提交
  6. 28 8月, 2008 1 次提交
    • H
      x86: generate names for /proc/cpuinfo from <asm/cpufeature.h> · 7414aa41
      H. Peter Anvin 提交于
      We have had a number of cases where <asm/cpufeature.h> (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: NH. Peter Anvin <hpa@zytor.com>
      7414aa41
  7. 04 2月, 2008 1 次提交