From: Ingo Molnar <mingo@elte.hu>
To: 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 11:05:01 +0200 [thread overview]
Message-ID: <20110525090501.GA28500@elte.hu> (raw)
In-Reply-To: <20110525080042.GA27183@liondog.tnic>
* Borislav Petkov <bp@alien8.de> wrote:
> On Wed, May 25, 2011 at 08:54:51AM +0200, Ingo Molnar wrote:
> >
> > * Andi Kleen <andi@firstfloor.org> wrote:
> >
> > > From: Andi Kleen <ak@linux.intel.com>
> > >
> > > I got a request to make it easier to determine the microcode update level
> > > on Intel CPUs. This patch adds a new "cpu update" field to /proc/cpuinfo,
> > > which I added at the end to minimize impact on parsers.
> >
> > Agreed, that is a good idea, adding this to cpuinfo makes sense.
>
> Frankly, I'm not even 100% persuaded this is needed. The coretemp.c
> jump-through-hoops to get the ucode revision is maybe the only case
> that warrants adding that field to /proc/cpuinfo.
I've often wondered whether the CPU involved in a particular
bugreport has the latest microcode installed.
Sure we have /sys/devices/system/cpu/cpuN/microcode/version, but
that's both privileged to get and also has to be asked for
separately.
Arguably the microcode version is a natural extension to the existing
family/model/stepping sequence:
cpu family : 6
model : 26
stepping : 5
We'd now see:
cpu family : 6
model : 26
stepping : 5
ucode_version : 17
Where 'stepping' is a hardware revison number and 'ucode_version' is
a dual software/hw revision number.
> > > @@ -111,6 +111,8 @@ struct cpuinfo_x86 {
> > > /* Index into per_cpu list: */
> > > u16 cpu_index;
> > > #endif
> > > + /* CPU update signature */
> > > + u32 x86_cpu_update;
> >
> > This should be cpu_microcode_version instead. We already know its x86 so the
> > x86_ prefix is superfluous. 'cpu_update' is also rather ambigious and does not
> > describe much.
>
> Or shorter: 'cpu_ucode_version'.
We already know it's a cpu data structure, since it's called 'struct
cpuinfo_x86' and the local variable is named 'c' which is the typical
shortcut for that data structure.
so c->ucode_version is the right name here.
Thanks,
Ingo
next prev parent reply other threads:[~2011-05-25 9:05 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 [this message]
2011-05-25 10:50 ` Borislav Petkov
2011-05-25 11:28 ` Ingo Molnar
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=20110525090501.GA28500@elte.hu \
--to=mingo@elte.hu \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=bp@alien8.de \
--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.