From: Borislav Petkov <bp@alien8.de>
To: Denys Vlasenko <dvlasenk@redhat.com>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
Borislav Petkov <bp@suse.de>, Jacob Shin <jacob.shin@amd.com>,
Jeff Layton <jlayton@redhat.com>,
Prarit Bhargava <prarit@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Fenghua Yu <fenghua.yu@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode
Date: Sun, 13 Apr 2014 18:09:24 +0200 [thread overview]
Message-ID: <20140413160924.GH25088@pd.tnic> (raw)
In-Reply-To: <5339A0F8.70606@redhat.com>
On Mon, Mar 31, 2014 at 07:08:08PM +0200, Denys Vlasenko wrote:
> What prompted me to create this patch is a bunch of vmcores
> from people having mysterious crashes.
>
> Basically, I am in a real-world scenario where I have only vmcore
> from somebody else. I have no /proc/cpuinfo.
>
> Every bit of information I don't have at a minimum incurs email
> round-trip delay.
>
> Eventually I did manage to figure out what version of microcode
> my users had (they did have old one), but it took some time.
Out of curiosity: the old microcode version wasn't the culprit for the
bug, was it?
> You are correct, the lack of boot-time dmesg is a problem for
> post-mortem vmcore analysis in general.
>
> I contemplate creating a patch to optionally save it.
Btw, can vmcore stash ucode version somewhere too, as part of the data
dump it saves? Or even the whole /proc/cpuinfo?
> That is not a bad thing: if my users would have been spooked that
> way, maybe they'd install a newer microcode. Or newer BIOS with new
> microcode - they did not do that either, despite it being available
> from the manufacturer for two years already.
Right, ok. So in thinking about this more. How about we drop the "bool
report_old" machinery and add those printks as debug printks? And by
that I mean,
printk(KERN_DEBUG...
and not all that other pr_debug() gunk?
This way, you need to boot with "debug" or "ignore_loglevel" on the
cmdline and they will get issued.
My concern is still with spooked users who'll come and say, my machine says:
+ pr_info("microcode: CPU rev 0x%x is same or newer"
+ " than 0x%x in microcode data\n",
Does that mean, I need to go and replace my CPU?
The usual case is that microcode gets upgraded with system upgrade as a
intel-ucode or amd-ucode or whatever package, so people upgrading their
distros will always get the latest ucode anyway.
Hmmm.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
prev parent reply other threads:[~2014-04-13 16:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-30 14:09 [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode Denys Vlasenko
2014-03-30 14:09 ` [PATCH 2/3] x86: microcode: report if no microcode file was found Denys Vlasenko
2014-03-31 16:26 ` Borislav Petkov
2014-03-30 14:09 ` [PATCH 3/3] x86: microcode: remove unused parameter and redundant variable Denys Vlasenko
2014-03-31 16:23 ` [PATCH 1/3] x86: microcode: report if CPU has up-to-date microcode Borislav Petkov
2014-03-31 17:08 ` Denys Vlasenko
2014-04-13 16:09 ` Borislav Petkov [this message]
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=20140413160924.GH25088@pd.tnic \
--to=bp@alien8.de \
--cc=bp@suse.de \
--cc=dvlasenk@redhat.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@linux.intel.com \
--cc=jacob.shin@amd.com \
--cc=jlayton@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=prarit@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.