Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751681AbdFAJ6T (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Jun 2017 05:58:19 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:35909 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751346AbdFAJ6S (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Jun 2017 05:58:18 -0400
Date: Thu, 1 Jun 2017 11:58:08 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Peter Zijlstra <peterz@infradead.org>
cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>, x86@kernel.org,
        linux-kernel@vger.kernel.org, kevin.b.stanton@intel.com, bp@alien8.de
Subject: Re: [PATCH 2/3] x86/apic: Add TSC_DEADLINE quirk due to errata
In-Reply-To: <20170601093549.iz5kzjju73har3qk@hirez.programming.kicks-ass.net>
Message-ID: <alpine.DEB.2.20.1706011148330.2470@nanos>
References: <20170531155201.218077283@infradead.org> <20170531155306.050849877@infradead.org> <20170531215855.GA5382@khazad-dum.debian.net> <20170601093549.iz5kzjju73har3qk@hirez.programming.kicks-ass.net>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1239
Lines: 32

On Thu, 1 Jun 2017, Peter Zijlstra wrote:
> That commit also states that is avoids a superfluous microcode load. And
> we've verified on affected systems (both Thomas and I have a SKL system
> with the PRMRR bit set in MTRRCAP) that when we manually load the
> microcode image the reported revision number matches the one from the
> image.
> 
>  [    0.000000] microcode: microcode updated early to revision 0xba, date = 2017-04-09
>  [    2.297894] microcode: sig=0x506e3, pf=0x2, revision=0xba
> 
> And:
> 
> # hexdump /lib/firmware/intel-ucode/06-5e-03 | head -1
> 0000000 0001 0000 00ba 0000 2017 0409 06e3 0005
>                   ^^^^^^^^^
> 
> So aside from a possible OS re-load of the microcode, the issue doesn't
> appear to have any negative effect.
> 
> 
> The microcode people (Cc'ed) might want to further look into this is
> they care about avoiding the superfluous reload, but for the purpose of
> this patch all is well.

Avoiding the superflous reload is dangerous. If the BIOS/FIT nonsense gets
fixed (however unlikely that is) then we run into an even worse problem
because then the kernel will not load version 5 if the CPU says version 4.
That's way worse than reloading the same version for nothing.

Thanks,

	tglx