On Tue, Jan 06, 2015 at 07:35:59PM +0100, Borislav Petkov wrote:
> Hi Greg,
>
> here are the upstream commits which are needed for the microcode loader
> on 3.18-stable. I'm testing on both 32- and 64-bit, AMD and Intel, just
> to be sure. This is 3.18-stable only, the others will follow as time
> allows.
>
> Here's the patchlist:
>
> 1. 2ef84b3bb97f ("x86, microcode, AMD: Do not use smp_processor_id() in
> preemtible context")
> 2. 47768626c6db ("x86, microcode, intel: Drop unused parameter")
> 3. a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
> paravirt")
> 4. fbae4ba8c4a3 ("x86, microcode: Reload microcode on resume")
> 5. 25cdb9c86826 ("x86/microcode/intel: Fish out the stashed microcode for the
> BSP")
>
> Between patches 4 and 5 you'll get a merge conflict which needs to be
> resolved like this:
>
> ---
> diff --git a/arch/x86/kernel/cpu/microcode/core.c
> b/arch/x86/kernel/cpu/microcode/core.c
> index 789648324abb..15c29096136b 100644
> --- a/arch/x86/kernel/cpu/microcode/core.c
> +++ b/arch/x86/kernel/cpu/microcode/core.c
> @@ -465,16 +465,8 @@ static void mc_bp_resume(void)
>
> if (uci->valid && uci->mc)
> microcode_ops->apply_microcode(cpu);
> -#ifdef CONFIG_X86_64
> else if (!uci->mc)
> - /*
> - * We might resume and not have applied late microcode but
> still
> - * have a newer patch stashed from the early loader. We don't
> - * have it in uci->mc so we have to load it the same way we're
> - * applying patches early on the APs.
> - */
> - load_ucode_ap();
> -#endif
> + reload_early_microcode();
> }
>
> static struct syscore_ops mc_syscore_ops = {
> --
>
> Thanks and let me know if there's trouble and I need to do anything.
Nope that worked fine, all now queued up, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
