Linux* Processor Microcode Data File

Linux* Processor Microcode Data File

[Dragoslav Zaric]

Hello,

I was browsing Intel web site for my processor docs and I bumped
on download link "Linux* Processor Microcode Data File" and it says
there:

"The microcode data file contains the latest microcode definitions for
all Intel processors.
Intel releases microcode updates to correct processor behavior as
documented in the respective
processor specification updates. While the regular approach to getting
this microcode update is via
a BIOS upgrade, Intel realizes that this can be an administrative
hassle. The Linux Operating System
and VMware ESX products have a mechanism to update the microcode after
booting. For example,
this file will be used by the operating system mechanism if the file
is placed in the /etc/firmware
directory of the Linux system."

So, does new kernel versions just copy this microcode update file in
/etc/firmware folder or new
instructions are replaced in assembly code ?

greet

Re: Linux* Processor Microcode Data File

[Jike Song]

On Mon, Mar 9, 2009 at 5:43 PM, Dragoslav Zaric
<dragoslav.zaric.kd@gmail.com> wrote:
> Hello,
>
> I was browsing Intel web site for my processor docs and I bumped
> on download link "Linux* Processor Microcode Data File" and it says
> there:
>
> "The microcode data file contains the latest microcode definitions for
> all Intel processors.
> Intel releases microcode updates to correct processor behavior as
> documented in the respective
> processor specification updates. While the regular approach to getting
> this microcode update is via
> a BIOS upgrade, Intel realizes that this can be an administrative
> hassle. The Linux Operating System
> and VMware ESX products have a mechanism to update the microcode after
> booting. For example,
> this file will be used by the operating system mechanism if the file
> is placed in the /etc/firmware
> directory of the Linux system."
>
> So, does new kernel versions just copy this microcode update file in
> /etc/firmware folder or new
> instructions are replaced in assembly code ?
>

Linux provides an microcode driver for Intel & AMD CPUs:

    arch/x86/kernel/microcode_*

and there is a service called "microcode_ctl" to open it and write the
microcode on every starting.   Where to find the microcode data is
this service specified, and the kernel doesn't care it.  You may want
to find:

http://www.urbanmyth.org/microcode/

> new  instructions are replaced in assembly code ?
As far as I can tell, no.   The microcode only only change the CPU's
behavior, not the assembler.


-- 
Thanks,
Jike

Re: Linux* Processor Microcode Data File

[Andreas Herrmann]

On Mon, Mar 09, 2009 at 06:00:35PM +0800, Jike Song wrote:
> On Mon, Mar 9, 2009 at 5:43 PM, Dragoslav Zaric
> <dragoslav.zaric.kd@gmail.com> wrote:
> > Hello,
> >
> > I was browsing Intel web site for my processor docs and I bumped
> > on download link "Linux* Processor Microcode Data File" and it says
> > there:
> >
> > "The microcode data file contains the latest microcode definitions for
> > all Intel processors.
> > Intel releases microcode updates to correct processor behavior as
> > documented in the respective
> > processor specification updates. While the regular approach to getting
> > this microcode update is via
> > a BIOS upgrade, Intel realizes that this can be an administrative
> > hassle. The Linux Operating System
> > and VMware ESX products have a mechanism to update the microcode after
> > booting. For example,
> > this file will be used by the operating system mechanism if the file
> > is placed in the /etc/firmware
> > directory of the Linux system."
> >
> > So, does new kernel versions just copy this microcode update file in
> > /etc/firmware folder or new
> > instructions are replaced in assembly code ?
> >
> 
> Linux provides an microcode driver for Intel & AMD CPUs:
> 
>     arch/x86/kernel/microcode_*
> 
> and there is a service called "microcode_ctl" to open it and write the
> microcode on every starting.   Where to find the microcode data is
> this service specified, and the kernel doesn't care it.  You may want
> to find:

> http://www.urbanmyth.org/microcode/

FYI, microcode patch loading for AMD CPUs uses only the firmware
loader interface. The patches for AMD CPUs are available from

http://www.amd64.org/support/microcode.html


Regards,
Andreas

-- 
Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

Re: Linux* Processor Microcode Data File

[Sitsofe Wheeler]

On Mon, Mar 09, 2009 at 10:43:57AM +0100, Dragoslav Zaric wrote:

> So, does new kernel versions just copy this microcode update file in
> /etc/firmware folder or new
> instructions are replaced in assembly code ?

The kernel doesn't load microcode automatically but it can provide a
device to allow userspace to trigger a microcode update (via
/dev/cpu/microcode ). On boot the patching process is normally started
by an initscript. See http://www.urbanmyth.org/microcode/ for details.

-- 
Sitsofe | http://sucs.org/~sits/

Re: Linux* Processor Microcode Data File

[Arjan van de Ven]

On Mon, 9 Mar 2009 10:43:57 +0100
Dragoslav Zaric <dragoslav.zaric.kd@gmail.com> wrote:

> Hello,
> 
> I was browsing Intel web site for my processor docs and I bumped
> on download link "Linux* Processor Microcode Data File" and it says
> there:
> 
> "The microcode data file contains the latest microcode definitions for
> all Intel processors.
> Intel releases microcode updates to correct processor behavior as
> documented in the respective
> processor specification updates. While the regular approach to getting
> this microcode update is via
> a BIOS upgrade, Intel realizes that this can be an administrative
> hassle. The Linux Operating System
> and VMware ESX products have a mechanism to update the microcode after
> booting. For example,
> this file will be used by the operating system mechanism if the file
> is placed in the /etc/firmware
> directory of the Linux system."
> 
> So, does new kernel versions just copy this microcode update file in
> /etc/firmware folder

yup just place it there.... and it'll get picked up.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux* Processor Microcode Data File

[Arjan van de Ven]

On Mon, 9 Mar 2009 14:16:55 +0000
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> On Mon, Mar 09, 2009 at 10:43:57AM +0100, Dragoslav Zaric wrote:
> 
> > So, does new kernel versions just copy this microcode update file in
> > /etc/firmware folder or new
> > instructions are replaced in assembly code ?
> 
> The kernel doesn't load microcode automatically 


it does if you have the right format; the kernel uses
request_firmware() for this.
The microcode on the intel website is not ready for this yet, but we're
working hard to have future drops to be in the new format.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux* Processor Microcode Data File

[Sitsofe Wheeler]

On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote:
> On Mon, 9 Mar 2009 14:16:55 +0000
> Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> 
> > The kernel doesn't load microcode automatically 
> 
> it does if you have the right format; the kernel uses
> request_firmware() for this.
> The microcode on the intel website is not ready for this yet, but we're
> working hard to have future drops to be in the new format.

Wow so I was redundant AND wrong in the same email!

What motivated the switch to the generic request_firmware interface? Is
it just less messy/faster than previous methods?

Additionally while I remember, is it worth updating the microcode on all
machines? At present I have an EeePC 900 and it's unclear if it would
benefit from a microcode update (but there's a definite cost to running
the current initscript at boot).

-- 
Sitsofe | http://sucs.org/~sits/

Re: Linux* Processor Microcode Data File

[Gene Heskett]

On Monday 09 March 2009, Sitsofe Wheeler wrote:
>On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote:
>> On Mon, 9 Mar 2009 14:16:55 +0000
>>
>> Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
>> > The kernel doesn't load microcode automatically
>>
>> it does if you have the right format; the kernel uses
>> request_firmware() for this.
>> The microcode on the intel website is not ready for this yet, but we're
>> working hard to have future drops to be in the new format.
>
>Wow so I was redundant AND wrong in the same email!
>
>What motivated the switch to the generic request_firmware interface? Is
>it just less messy/faster than previous methods?
>
>Additionally while I remember, is it worth updating the microcode on all
>machines? At present I have an EeePC 900 and it's unclear if it would
>benefit from a microcode update (but there's a definite cost to running
>the current initscript at boot).

Slight hijack of thread here, but...

I'll have to admit it was with some trepidation that I might brick my 
processor, which is a quad core AMD 9550, stepping 03 running at 2.2 ghz, but 
the directions didn't note until the end, that it would take a 2.6.29 series 
kernel to do it and I was running 2.6.28.7.  But when I got to the 
modprobe -r microcode, modprobe microcode part, there was no feedback from 
either command.  So did I, or did I not do this as I was and am running 
2.6.28.7?  The following was reported in my log:

Mar  9 07:22:04 coyote kernel: [65725.810333] microcode: collect_cpu_info_amd : patch_id=0x1000065                                       
Mar  9 07:22:04 coyote kernel: [65725.810338] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
Mar  9 07:22:04 coyote kernel: [65725.847258] microcode: size 1936, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.847265] microcode: CPU0 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022)
Mar  9 07:22:04 coyote kernel: [65725.847269] microcode: size 968, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.847278] microcode: CPU0 updated from revision 0x1000065 to 0x1000083
Mar  9 07:22:04 coyote kernel: [65725.847312] microcode: collect_cpu_info_amd : patch_id=0x1000065
Mar  9 07:22:04 coyote kernel: [65725.847317] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
Mar  9 07:22:04 coyote kernel: [65725.851377] microcode: size 1936, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.851390] microcode: CPU1 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022)
Mar  9 07:22:04 coyote kernel: [65725.851393] microcode: size 968, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.851403] microcode: CPU1 updated from revision 0x1000065 to 0x1000083
Mar  9 07:22:04 coyote kernel: [65725.851421] microcode: collect_cpu_info_amd : patch_id=0x1000065
Mar  9 07:22:04 coyote kernel: [65725.851426] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
Mar  9 07:22:04 coyote kernel: [65725.855323] microcode: size 1936, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.855330] microcode: CPU2 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022)
Mar  9 07:22:04 coyote kernel: [65725.855333] microcode: size 968, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.855344] microcode: CPU2 updated from revision 0x1000065 to 0x1000083
Mar  9 07:22:04 coyote kernel: [65725.855361] microcode: collect_cpu_info_amd : patch_id=0x1000065
Mar  9 07:22:04 coyote kernel: [65725.855365] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
Mar  9 07:22:04 coyote kernel: [65725.863101] microcode: size 1936, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022)
Mar  9 07:22:04 coyote kernel: [65725.863110] microcode: size 968, total_size 960
Mar  9 07:22:04 coyote kernel: [65725.863120] microcode: CPU3 updated from revision 0x1000065 to 0x1000083
Mar  9 07:22:04 coyote kernel: [65725.863122] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Inquiring minds and all that.  Comments please?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
"I have five dollars for each of you."
-- Bernhard Goetz

Re: Linux* Processor Microcode Data File

[Sitsofe Wheeler]

At the risk of being wrong twice in a row...

On Mon, Mar 09, 2009 at 11:58:22AM -0400, Gene Heskett wrote:
> I'll have to admit it was with some trepidation that I might brick my 
> processor, which is a quad core AMD 9550, stepping 03 running at 2.2 ghz, but 

Microcode patching in this particular fashion (i.e. _not_ updating the
BIOS but "on the fly") is volatile (so it has to be redone at every
boot) which should mean it is very hard to brick a machine this way as
rebooting will undo everything. Of course someone is going to tell me
how they managed to kill a machine stone dead due to some sequence of
events I hadn't thought of and I disclaim any responsiblity if someone
tries to update their microcode and harms their machine in any fashion -
you update at your own risk :).

> the directions didn't note until the end, that it would take a 2.6.29 series 
> kernel to do it and I was running 2.6.28.7.  But when I got to the 
> modprobe -r microcode, modprobe microcode part, there was no feedback from 
> either command.  So did I, or did I not do this as I was and am running 
> 2.6.28.7?  The following was reported in my log:

modprobe generally doesn't return much if the module in question loads
or (as in this case because you were using -r) is removed. That's the
typical Unix command line behviour - no response/output on "OK".

> Mar  9 07:22:04 coyote kernel: [65725.855365] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
> Mar  9 07:22:04 coyote kernel: [65725.863101] microcode: size 1936, total_size 960
> Mar  9 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022)
> Mar  9 07:22:04 coyote kernel: [65725.863110] microcode: size 968, total_size 960
> Mar  9 07:22:04 coyote kernel: [65725.863120] microcode: CPU3 updated from revision 0x1000065 to 0x1000083
> Mar  9 07:22:04 coyote kernel: [65725.863122] Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
> 
> Inquiring minds and all that.  Comments please?

It looks like the firmware file (amd-ucode/microcode_amd.bin) doesn't
match your processor. CC'ing Andreas for comment as you have an AMD
machine...

-- 
Sitsofe | http://sucs.org/~sits/

Re: Linux* Processor Microcode Data File

[Arjan van de Ven]

On Mon, 9 Mar 2009 15:34:50 +0000
Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote:
> > On Mon, 9 Mar 2009 14:16:55 +0000
> > Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> > 
> > > The kernel doesn't load microcode automatically 
> > 
> > it does if you have the right format; the kernel uses
> > request_firmware() for this.
> > The microcode on the intel website is not ready for this yet, but
> > we're working hard to have future drops to be in the new format.
> 
> Wow so I was redundant AND wrong in the same email!
> 
> What motivated the switch to the generic request_firmware interface?
> Is it just less messy/faster than previous methods? 

there are various cases where microcode is needed (for example, when
you hotplug a new cpu); request_firmware() is just the right way to do
such things, and an initscript is just the wrong way

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux* Processor Microcode Data File

[Gene Heskett]

On Monday 09 March 2009, Sitsofe Wheeler wrote:
>At the risk of being wrong twice in a row...
>
>On Mon, Mar 09, 2009 at 11:58:22AM -0400, Gene Heskett wrote:
>> I'll have to admit it was with some trepidation that I might brick my
>> processor, which is a quad core AMD 9550, stepping 03 running at 2.2 ghz,
>> but
>
>Microcode patching in this particular fashion (i.e. _not_ updating the
>BIOS but "on the fly") is volatile (so it has to be redone at every
>boot) which should mean it is very hard to brick a machine this way as
>rebooting will undo everything. Of course someone is going to tell me
>how they managed to kill a machine stone dead due to some sequence of
>events I hadn't thought of and I disclaim any responsiblity if someone
>tries to update their microcode and harms their machine in any fashion -
>you update at your own risk :).
>
>> the directions didn't note until the end, that it would take a 2.6.29
>> series kernel to do it and I was running 2.6.28.7.  But when I got to the
>> modprobe -r microcode, modprobe microcode part, there was no feedback from
>> either command.  So did I, or did I not do this as I was and am running
>> 2.6.28.7?  The following was reported in my log:
>
>modprobe generally doesn't return much if the module in question loads
>or (as in this case because you were using -r) is removed. That's the
>typical Unix command line behviour - no response/output on "OK".
>
>> Mar  9 07:22:04 coyote kernel: [65725.855365] platform microcode:
>> firmware: requesting amd-ucode/microcode_amd.bin Mar  9 07:22:04 coyote
>> kernel: [65725.863101] microcode: size 1936, total_size 960 Mar  9
>> 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch does not
>> match (processor_rev_id: 1020, eqiv_cpu_id: 1022) Mar  9 07:22:04 coyote
>> kernel: [65725.863110] microcode: size 968, total_size 960 Mar  9 07:22:04
>> coyote kernel: [65725.863120] microcode: CPU3 updated from revision
>> 0x1000065 to 0x1000083 Mar  9 07:22:04 coyote kernel: [65725.863122]
>> Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
>>
>> Inquiring minds and all that.  Comments please?
>
>It looks like the firmware file (amd-ucode/microcode_amd.bin) doesn't
>match your processor. CC'ing Andreas for comment as you have an AMD
>machine...

Thank You.  But the text report above also says it did update it, hence the 
confusion.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
For fast-acting relief, try slowing down.

Re: Linux* Processor Microcode Data File

[Andreas Herrmann]

On Mon, Mar 09, 2009 at 04:24:16PM +0000, Sitsofe Wheeler wrote:
> On Mon, Mar 09, 2009 at 11:58:22AM -0400, Gene Heskett wrote:
> > Mar  9 07:22:04 coyote kernel: [65725.855365] platform microcode: firmware: requesting amd-ucode/microcode_amd.bin

    ...

> > Mar 9 07:22:04 coyote kernel: [65725.863107] microcode: CPU3 patch
> > does not match (processor_rev_id: 1020, eqiv_cpu_id: 1022) is
> > printed.

This line should better be a debug message. There can be several
ucode-patches in amd-ucode/microcode_amd.bin. The kernel code checks
whether those patches match the CPU revision and if a patch doesn't
match, one such a line shows up. (which is ... obfuscating)

I'll fix this asap in mainline, but IMHO it's not worth to fix this in
.28.

> > Mar 9 07:22:04 coyote kernel: [65725.863120] microcode: CPU3
> > updated from revision 0x1000065 to 0x1000083

Finally CPU microcode was updated as this message is indicating.


Regards,
Andreas


PS: You can check the microcode patch level of your AMD family 10h and
    11h CPU by reading MSR 0x0000008b. E.g. using lsmsr from x86info
    package shows

    # lsmsr -r 0x0000008b -c 0
    PATCH_LEVEL = 0x0000000001000065


-- 
Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
 Research | Geschäftsführer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
  (OSRC)  | Registergericht München, HRB Nr. 43632

Re: Linux* Processor Microcode Data File

[Giacomo A. Catenazzi]

Arjan van de Ven wrote:
> On Mon, 9 Mar 2009 15:34:50 +0000
> Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> 
>> On Mon, Mar 09, 2009 at 08:11:09AM -0700, Arjan van de Ven wrote:
>>> On Mon, 9 Mar 2009 14:16:55 +0000
>>> Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
>>>
>>>> The kernel doesn't load microcode automatically 
>>> it does if you have the right format; the kernel uses
>>> request_firmware() for this.
>>> The microcode on the intel website is not ready for this yet, but
>>> we're working hard to have future drops to be in the new format.
>> Wow so I was redundant AND wrong in the same email!
>>
>> What motivated the switch to the generic request_firmware interface?
>> Is it just less messy/faster than previous methods? 
> 
> there are various cases where microcode is needed (for example, when
> you hotplug a new cpu); request_firmware() is just the right way to do
> such things, and an initscript is just the wrong way

I don't agree ;-)
I agree that request_firmware method is better than init.d scripts, but
not that it is the right things. microcodes should be loaded at very
beginning of boot process, so by BIOS, by GRUB or on hotpug event by
request_firmware.
BTW: why do we have microcode loading modular?

Offtopic: IMHO if we could move the load of firmware before booting
linux, it would be nicer and cleaner (by open source point of view).

ciao
	cate

Re: Linux* Processor Microcode Data File

[Arjan van de Ven]

On Thu, 12 Mar 2009 11:03:11 +0100
"Giacomo A. Catenazzi" <cate@cateee.net> wrote:

> > 
> > there are various cases where microcode is needed (for example, when
> > you hotplug a new cpu); request_firmware() is just the right way to
> > do such things, and an initscript is just the wrong way
> 
> I don't agree ;-)
> I agree that request_firmware method is better than init.d scripts,
> but not that it is the right things. microcodes should be loaded at
> very beginning of boot process, so by BIOS, by GRUB or on hotpug
> event by request_firmware.

... and how do you do CPU hotplug then ?

> BTW: why do we have microcode loading modular?

only the legacy initscript part is modular afaik.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: Linux* Processor Microcode Data File

[Dragoslav Zaric]

I agree with you 100%, and I think that GRUB should do that loading and new
kernel version should supply newest and tested microcode.

Re: Linux* Processor Microcode Data File

[Giacomo A. Catenazzi]

Arjan van de Ven wrote:
> On Thu, 12 Mar 2009 11:03:11 +0100
> "Giacomo A. Catenazzi" <cate@cateee.net> wrote:
> 
>>> there are various cases where microcode is needed (for example, when
>>> you hotplug a new cpu); request_firmware() is just the right way to
>>> do such things, and an initscript is just the wrong way
>> I don't agree ;-)
>> I agree that request_firmware method is better than init.d scripts,
>> but not that it is the right things. microcodes should be loaded at
>> very beginning of boot process, so by BIOS, by GRUB or on hotpug
>> event by request_firmware.
> 
> ... and how do you do CPU hotplug then ?

and system that doesn't use GRUB vX.Y, and ...

The driver in kernel should remain, for hotplug (CPU not completely
initialized) and for the other cases.

But my argument is that microcode loading in kernel, in "other cases"
is not optimal.
IIRC Intel documentation recommends to update microcodes in BIOS
(before full initialize all registers).

Anyway the "GRUB" proposal will be as an additional way, like BIOS
update: try to load microcode earlier as possible. The worse case
will be done very late, at new package installation time.

But now I've an other doubt:
Users asked me for a script that check and update microcode as
cronjob (I hope nobody will use extreme short "polling" periods to
Intel server.).
Updating microcode at full running time is not supported by
update_firmware method, right?
Is it the correct bahaviour? (according the "load earlier" I think
yes, but maybe I miss something)

>> BTW: why do we have microcode loading modular?
> 
> only the legacy initscript part is modular afaik.

ok

ciao
	cate

Linux* Processor Microcode Data File

[Dragoslav Zaric]

---------------------------------------------
I found this on web site http://kerneltrap.org

Tigran Aivazian, author of the IA32 microcode driver and Microcode
Update Utility for Linux explained:

"The answer to your question is that some Intel CPUs (just like any
other hardware or software) contain bugs
and, fortunately, their architecture is flexible enough to provide a
way to fix those bugs by means of loading the
microcode update on the fly, i.e. while the OS is running with no need
to reboot (in fact, rebooting or otherwise
resetting the CPU causes the update to be lost and requires to run the
update again)."
---------------------------------------------

So when you reboot system, you reset CPU to original state, and after
that you must apply microcode, and this
is what is actually doing right now, you put microcode in folder
/etc/firmware and after boot microcode is loaded.

So I think for CPU hotplug it is also natural that microcode is loaded
after plugging, because you can not use
microcode from boot process. Maybe kernel should have database of
tested microcodes, so when you plug CPU
appropriate microcode is loaded.



-- 
Thanks

Dragoslav Zaric
[Programmer ; M.Sc. in Astrophysics]

Re: Linux* Processor Microcode Data File

[Gene Heskett]

On Friday 13 March 2009, Dragoslav Zaric wrote:
>---------------------------------------------
>I found this on web site http://kerneltrap.org
>
>Tigran Aivazian, author of the IA32 microcode driver and Microcode
>Update Utility for Linux explained:
>
>"The answer to your question is that some Intel CPUs (just like any
>other hardware or software) contain bugs
>and, fortunately, their architecture is flexible enough to provide a
>way to fix those bugs by means of loading the
>microcode update on the fly, i.e. while the OS is running with no need
>to reboot (in fact, rebooting or otherwise
>resetting the CPU causes the update to be lost and requires to run the
>update again)."

And what runs this update?  I saw it apply once in the dmesg output, about 3 
full powerdown reboots ago, never since, and the code is still there in 
/lib/firmware

AMD quad core 9550 here, stepping 03.

Thanks.
>---------------------------------------------
>
>So when you reboot system, you reset CPU to original state, and after
>that you must apply microcode, and this
>is what is actually doing right now, you put microcode in folder
>/etc/firmware and after boot microcode is loaded.
>
>So I think for CPU hotplug it is also natural that microcode is loaded
>after plugging, because you can not use
>microcode from boot process. Maybe kernel should have database of
>tested microcodes, so when you plug CPU
>appropriate microcode is loaded.


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The only thing that experience teaches us is that experience teaches us 
nothing.
		-- Andre Maurois (Emile Herzog)