From: Ingo Molnar <mingo@elte.hu>
To: Borislav Petkov <bp@amd64.org>
Cc: Borislav Petkov <bp@alien8.de>, Andi Kleen <andi@firstfloor.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 1/3] x86, intel: Output microcode revision
Date: Wed, 25 May 2011 13:28:52 +0200 [thread overview]
Message-ID: <20110525112852.GD30983@elte.hu> (raw)
In-Reply-To: <20110525105057.GA21830@gere.osrc.amd.com>
* Borislav Petkov <bp@amd64.org> wrote:
> Btw, can we dump the ucode version in hex since ours are much easier to
> read that way:
>
> [86483.770976] microcode: CPU0: patch_level=0x010000c4
> [86483.826987] microcode: CPU1: patch_level=0x010000c4
> [86483.835071] microcode: CPU2: patch_level=0x010000c4
> ...
How is that version constructed and iterated, or example is the
0x01000000 bit always set?
If it's always set then it might make sense to turn this into a more
human-readable version number: mask out the 0x01000000 and report
0xc4 as 194? Or is the *real* version above just '4'?
Should 0x010000c4 perhaps be printed as 1.10.4?
> I guess for Intel the ucode version format won't matter that much.
Well, if Intel does similar encodings as AMD, then it would be nice
to turn that into human-readable version strings as well.
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-25 11:29 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 23:03 [PATCH 1/3] x86, intel: Output microcode revision Andi Kleen
2011-05-24 23:03 ` [PATCH 2/3] x86, intel: Use cpu_update for Atom errata check Andi Kleen
2011-05-25 6:59 ` Ingo Molnar
2011-05-24 23:03 ` [PATCH 3/3] coretemp: Get microcode revision from cpu_data Andi Kleen
2011-05-24 23:58 ` Yu, Fenghua
2011-05-25 0:39 ` [PATCH 1/3] x86, intel: Output microcode revision Fenghua Yu
[not found] ` <BANLkTikoa494-bRWtbbXuE6eqLuH0ZPUTg@mail.gmail.com>
[not found] ` <493994B35A117E4F832F97C4719C4C04011E214EC2@orsmsx505.amr.corp.intel.com>
2011-05-25 0:47 ` Andi Kleen
2011-05-25 6:54 ` Ingo Molnar
2011-05-25 8:00 ` Borislav Petkov
2011-05-25 9:05 ` Ingo Molnar
2011-05-25 10:50 ` Borislav Petkov
2011-05-25 11:28 ` Ingo Molnar [this message]
2011-05-25 21:08 ` Borislav Petkov
2011-05-25 11:30 ` Ingo Molnar
2011-05-25 16:54 ` Andi Kleen
2011-05-25 18:59 ` Ingo Molnar
2011-05-25 19:13 ` Andi Kleen
2011-05-25 7:06 ` Ingo Molnar
2011-05-25 16:06 ` Henrique de Moraes Holschuh
2011-05-25 16:58 ` Andi Kleen
2011-05-25 18:24 ` Ingo Molnar
2011-05-25 19:04 ` Henrique de Moraes Holschuh
2011-05-25 19:36 ` Ingo Molnar
2011-05-25 19:05 ` Andi Kleen
2011-05-25 19:45 ` Ingo Molnar
2011-05-29 10:21 ` Jan Ceuleers
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=20110525112852.GD30983@elte.hu \
--to=mingo@elte.hu \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--cc=bp@amd64.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--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 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.