All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dragoslav Zaric <dragoslav.zaric.kd@gmail.com>
To: LKML <linux-kernel@vger.kernel.org>
Subject: Linux* Processor Microcode Data File
Date: Fri, 13 Mar 2009 09:44:02 +0100	[thread overview]
Message-ID: <2d05c4580903130144t8e92950l7a6cb1078a8a577b@mail.gmail.com> (raw)
In-Reply-To: <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com>

---------------------------------------------
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]

  parent reply	other threads:[~2009-03-13  8:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-09  9:43 Linux* Processor Microcode Data File Dragoslav Zaric
2009-03-09 10:00 ` Jike Song
2009-03-09 10:30   ` Andreas Herrmann
2009-03-09 14:16 ` Sitsofe Wheeler
2009-03-09 15:11   ` Arjan van de Ven
2009-03-09 15:34     ` Sitsofe Wheeler
2009-03-09 15:58       ` Gene Heskett
2009-03-09 16:24         ` Sitsofe Wheeler
2009-03-09 17:03           ` Gene Heskett
2009-03-09 17:57           ` Andreas Herrmann
2009-03-09 16:53       ` Arjan van de Ven
2009-03-12 10:03         ` Giacomo A. Catenazzi
2009-03-12 14:07           ` Arjan van de Ven
2009-03-13  8:37             ` Giacomo A. Catenazzi
     [not found]             ` <2d05c4580903130142o2e5ebbcfw1e35eb52ea48e4b1@mail.gmail.com>
2009-03-13  8:44               ` Dragoslav Zaric [this message]
2009-03-13 14:55                 ` Gene Heskett
2009-03-12 14:53           ` Dragoslav Zaric
2009-03-09 14:27 ` Arjan van de Ven

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=2d05c4580903130144t8e92950l7a6cb1078a8a577b@mail.gmail.com \
    --to=dragoslav.zaric.kd@gmail.com \
    --cc=linux-kernel@vger.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.