[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