[3.16.y-ckt stable] Patch "x86, microcode: Update BSPs microcode on resume" has been added to staging queue

Luis Henriques luis.henriques at canonical.com
Mon Dec 1 10:32:16 UTC 2014


On Mon, Dec 01, 2014 at 11:23:26AM +0100, Borislav Petkov wrote:
> Hey Luis,
> 
> please drop this patch for now as it breaks 32-bit suspend to ram. I'll
> have a full list of patches for stable once the whole issue has been
> sorted out properly.
> 
> Thanks.
> 

Ouch!  I had dropped this patch before but somehow I managed to queue
it again (I need to go look at my scripts and see what's broken).
Thanks for catching this, Boris!

Cheers,
--
Luís

> On Mon, Dec 01, 2014 at 10:19:51AM +0000, Luis Henriques wrote:
> > This is a note to let you know that I have just added a patch titled
> > 
> >     x86, microcode: Update BSPs microcode on resume
> > 
> > to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
> > which can be found at:
> > 
> >  http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y-queue
> > 
> > This patch is scheduled to be released in version 3.16.7-ckt3.
> > 
> > If you, or anyone else, feels it should not be added to this tree, please 
> > reply to this email.
> > 
> > For more information about the 3.16.y-ckt tree, see
> > https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
> > 
> > Thanks.
> > -Luis
> > 
> > ------
> > 
> > From 76c27f3e62e96a4e4a4591fb3861048ec171b006 Mon Sep 17 00:00:00 2001
> > From: Borislav Petkov <bp at suse.de>
> > Date: Tue, 18 Nov 2014 10:46:57 +0100
> > Subject: x86, microcode: Update BSPs microcode on resume
> > 
> > commit fb86b97300d930b57471068720c52bfa8622eab7 upstream.
> > 
> > In the situation when we apply early microcode but do *not* apply late
> > microcode, we fail to update the BSP's microcode on resume because we
> > haven't initialized the uci->mc microcode pointer. So, in order to
> > alleviate that, we go and dig out the stashed microcode patch during
> > early boot. It is basically the same thing that is done on the APs early
> > during boot so do that too here.
> > 
> > Tested-by: alex.schnaidt at gmail.com
> > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
> > Cc: Henrique de Moraes Holschuh <hmh at hmh.eng.br>
> > Cc: Fenghua Yu <fenghua.yu at intel.com>
> > Signed-off-by: Borislav Petkov <bp at suse.de>
> > Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
> > Signed-off-by: Thomas Gleixner <tglx at linutronix.de>
> > Signed-off-by: Luis Henriques <luis.henriques at canonical.com>
> > ---
> >  arch/x86/kernel/cpu/microcode/core.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c
> > index dd9d6190b08d..2ce9051174e6 100644
> > --- a/arch/x86/kernel/cpu/microcode/core.c
> > +++ b/arch/x86/kernel/cpu/microcode/core.c
> > @@ -465,6 +465,14 @@ static void mc_bp_resume(void)
> > 
> >  	if (uci->valid && uci->mc)
> >  		microcode_ops->apply_microcode(cpu);
> > +	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();
> >  }
> > 
> >  static struct syscore_ops mc_syscore_ops = {
> > --
> > 2.1.0
> > 
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --




More information about the kernel-team mailing list