1. 07 6月, 2015 1 次提交
  2. 06 5月, 2015 1 次提交
    • B
      x86/microcode: Parse built-in microcode early · 760d765b
      Borislav Petkov 提交于
      Apparently, people do build microcode into the kernel image, i.e.
      CONFIG_FIRMWARE_IN_KERNEL=y.
      
      Make that work in the early loader which is where microcode should be
      preferably loaded anyway.
      
      Note that you need to specify the microcode filename with the path
      relative to the toplevel firmware directory (the same like the late
      loading method) in CONFIG_EXTRA_FIRMWARE=y so that early loader can
      find it.
      
      I.e., something like this (Intel variant):
      
        CONFIG_FIRMWARE_IN_KERNEL=y
        CONFIG_EXTRA_FIRMWARE="intel-ucode/06-3a-09"
        CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
      
      While at it, add me to the loader copyright boilerplate.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Daniel J Blueman <daniel@numascale.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      760d765b
  3. 06 12月, 2014 1 次提交
    • B
      x86, microcode: Reload microcode on resume · fbae4ba8
      Borislav Petkov 提交于
      Normally, we do reapply microcode on resume. However, in the cases where
      that microcode comes from the early loader and the late loader hasn't
      been utilized yet, there's no easy way for us to go and apply the patch
      applied during boot by the early loader.
      
      Thus, reuse the patch stashed by the early loader for the BSP.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      fbae4ba8
  4. 01 12月, 2014 1 次提交
  5. 14 1月, 2014 1 次提交
    • B
      x86, microcode, AMD: Fix early ucode loading · 5335ba5c
      Borislav Petkov 提交于
      The original idea to use the microcode cache for the APs doesn't pan out
      because we do memory allocation there very early and with IRQs disabled
      and we don't want to involve GFP_ATOMIC allocations. Not if it can be
      helped.
      
      Thus, extend the caching of the BSP patch approach to the APs and
      iterate over the ucode in the initrd instead of using the cache. We
      still save the relevant patches to it but later, right before we
      jettison the initrd.
      
      While at it, fix early ucode loading on 32-bit too.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Tested-by: NAravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
      5335ba5c
  6. 13 8月, 2013 1 次提交
    • T
      x86, microcode, AMD: Fix early microcode loading · 84516098
      Torsten Kaiser 提交于
      load_microcode_amd() (and the helper it is using) should not have an
      cpu parameter. The microcode loading does not depend on the CPU wrt the
      patches loaded since they will end up in a global list for all CPUs
      anyway.
      
      The change from cpu to x86family in load_microcode_amd()
      now allows to drop the code messing with cpu_data(cpu) from
      collect_cpu_info_amd_early(), which is wrong anyway because at that
      point the per-cpu cpu_info is not yet setup (These values would later be
      overwritten by smp_store_boot_cpu_info() / smp_store_cpu_info()).
      
      Fold the rest of collect_cpu_info_amd_early() into load_ucode_amd_ap(),
      because its only used at one place and without the cpuinfo_x86 accesses
      it was not much left.
      Signed-off-by: NTorsten Kaiser <just.for.lkml@googlemail.com>
      [ Fengguang: build fix ]
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      [ Boris: adapt it to current tree. ]
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      84516098
  7. 15 7月, 2013 1 次提交
    • P
      x86: delete __cpuinit usage from all x86 files · 148f9bb8
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      are flagged as __cpuinit  -- so if we remove the __cpuinit from
      arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      content into no-ops as early as possible, since that will get rid
      of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the arch/x86 uses of the __cpuinit macros from
      all C files.  x86 only had the one __CPUINIT used in assembly files,
      and it wasn't paired off with a .previous or a __FINIT, so we can
      delete it directly w/o any corresponding additional change there.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: x86@kernel.org
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      148f9bb8
  8. 01 6月, 2013 1 次提交
  9. 31 5月, 2013 2 次提交