[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120614135401.GA24491@khazad-dum.debian.net>
Date: Thu, 14 Jun 2012 10:54:01 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Borislav Petkov <bp@...en8.de>, Andi Kleen <andi@...stfloor.org>,
x86@...nel.org, linux-kernel@...r.kernel.org, eranian@...gle.com,
peterz@...radead.org, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH 1/4] x86: Do microcode updates at CPU_STARTING, not
CPU_ONLINE
On Thu, 14 Jun 2012, Borislav Petkov wrote:
> On Wed, Jun 13, 2012 at 01:20:39PM -0700, Andi Kleen wrote:
> > case CPU_ONLINE:
> > case CPU_ONLINE_FROZEN:
> > - microcode_update_cpu(cpu);
> > + /* Retry again in case we couldn't request early */
> > + if (cpu_data(cpu).microcode < ucode_cpu_info[cpu].cpu_sig.rev)
> > + microcode_update_cpu_late(cpu);
>
> This implies newer ucode versions are numerically higher than
> what's currently present. And it is probably correct in the 99% of
> the cases but it would be more correct IMHO to have "!=" there.
> microcode_update_cpu_late takes care of checking the correct ucode
> version anyway down the path.
Indeed. For Intel, the microcode rev is a *signed* value, and the
intended way for it to work is that you always install negative rev
microcode (used only internally at Intel, I am told), or install
microcode if rev(new microcode) > rev (old microcode) >= 0, and refuse
to install if rev(new microcode) == 0.
It is better to use != and have stricter checks in the vendor-specific
code.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists