From: Petr Oros <poros@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/microcode/intel: print previous microcode revision during early update
Date: Thu, 01 Feb 2018 19:40:22 +0100 [thread overview]
Message-ID: <1517510422.2755.5.camel@redhat.com> (raw)
In-Reply-To: <20180126144918.7jiaezmdhjsiman5@pd.tnic>
Borislav Petkov píše v Pá 26. 01. 2018 v 15:49 +0100:
> On Fri, Jan 26, 2018 at 02:50:00PM +0100, Petr Oros wrote:
> > But what in production? Edit boot params, restart server, grep /proc/cpuinfo and
> > restart again? Why i can not read it just from dmesg?
>
> Because you don't need the previous revision.
>
> You only *happen* to need it now but that is being addressed too with
> the blacklisting. And when you have broken microcode, it will say:
>
> + pr_warn("Intel Spectre v2 broken microcode detected; disabling SPEC_CTRL\n");
>
> and if you have microcode which doesn't have IBRS, there won't be
> "spec_ctrl" in /proc/cpuinfo.
>
> I don't want people to start paying attention to microcode
> revision numbers with the gazillion different revisions and
> family/model/steppings out there and the crazy confusion that will ensue
> from this.
>
We talk about dmesg log, it is place for diagnostic messages.
I think, people expected gazillion numbers here.
I adding only one number (microcode version) into log and only if patch is
applied. This is good also for future bugs, and for example for tools like
sosreport.
It is really better to have microcode version ready and not try find it and try
to collect after problem...
Btw: with hot microcode patch is possible to get previous version from dmesg
[ 0.680519] microcode: sig=0x306c3, pf=0x10, revision=0x23
Only with early it is not possible.
Thanks,
-Petr
next prev parent reply other threads:[~2018-02-01 18:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-26 10:34 [PATCH] x86/microcode/intel: print previous microcode revision during early update Petr Oros
2018-01-26 10:41 ` Borislav Petkov
2018-01-26 11:45 ` Petr Oros
2018-01-26 11:58 ` Borislav Petkov
2018-01-26 13:50 ` Petr Oros
2018-01-26 14:49 ` Borislav Petkov
2018-02-01 18:40 ` Petr Oros [this message]
2018-02-07 14:02 ` Stanislav Kozina
2018-02-07 15:21 ` Borislav Petkov
2018-02-07 20:05 ` Stanislav Kozina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1517510422.2755.5.camel@redhat.com \
--to=poros@redhat.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox