The URL: http://www.urbanmyth.org/microcode/
The microcode_ctl utility is a companion to the IA32 microcode driver
written by Tigran Aivazian <[email protected]>. The utility has two uses:
* it decodes and sends new microcode to the kernel driver to be uploaded
to Intel IA32 processors. (Pentium Pro, PII, PIII, Pentium 4, Celeron, Xeon
etc - all P6 and above, which does NOT include pentium classics)
* it signals the kernel driver to release any buffers it may hold
The microcode update is volatile and needs to be uploaded on each system
boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts
back to the old microcode.
My question is, what are the advantages vs disadvantages in updating your
CPU's microcode?
Is it worth it?
Does it matter what type of Intel CPU you have?
Do some CPU's benefit more than others for microcode updates?
I know RedHat distributions usually do this by default, but others do not.
Can anyone explain reasons to or not to update the CPU microcode?
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar ? get it now!
http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/
On Thu, 18 Mar 2004, Justin Piszcz wrote:
[SNIPPED...]
>
> My question is, what are the advantages vs disadvantages in updating your
> CPU's microcode?
>
> Is it worth it?
Remember the CPU with the f00f bug? How about the FP unit bug?
With ucode updates, those bugs can be fixed with zero overhead,
just an additional second or two of boot-time.
>
> Does it matter what type of Intel CPU you have?
>
Of course, some don't have WCS (Writable control-store) and
therefore can't be updated.
> Do some CPU's benefit more than others for microcode updates?
>
Only the broken ones.
>
> Can anyone explain reasons to or not to update the CPU microcode?
>
"If it ain't broke, don't fix it.".... But there are some people
who want the "latest and greatest" even though there is no performance
change at all.
When new CPUs hit the market there are some "immature features", i.e.,
BUGS. With a WCS, micro-code work-arounds can be provided so that
the CPU doesn't have to be thrown away. If you use the wrong micro-
code, perhaps the "latest and greatest", you may actually break
the CPU because the work-arounds go away.
Review the stuff on http://www.x86.org. Even though it's slanted
far to the left, there is some good information there.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, Mar 18, 2004 at 04:40:49PM +0000, Justin Piszcz wrote:
> My question is, what are the advantages vs disadvantages in updating your
> CPU's microcode?
It'll fix known problems in the microcode thats in ROM on your CPU.
> Is it worth it?
In most cases, yes. It's zero cost. You don't waste RAM, as the
microcode gets loaded into small RAM areas on the CPU that are
otherwise unused.
> Does it matter what type of Intel CPU you have?
yes. You need at least a Pentium Pro.
Also Pentium 4 needs a newer format microcode, which isn't available
publically anywhere yet afaik.
> Do some CPU's benefit more than others for microcode updates?
Some CPUs have more bugs that need fixing than others 8)
Additionally some CPUs may not have a newer microcode available
than the one that it shipped with in ROM
> Can anyone explain reasons to or not to update the CPU microcode?
In some cases, your BIOS is doing this transparently already.
I've seen instances where moving a CPU between two motherboards
has meant that microcode_ctl has done an upgrade on one, and
done nothing on the other as its already up to date.
If you're already up-to-date, theres no reason to run it.
Dave
On Thu, 2004-03-18 at 11:59, Richard B. Johnson wrote:
> Review the stuff on http://www.x86.org. Even though it's slanted
> far to the left, there is some good information there.
The good-ol-boys, Dr. Dobb's? Slanted to the left? More like far right
to me ;-)
Robert Love
> > Is it worth it?
> In most cases, yes. It's zero cost. You don't waste RAM, as the
> microcode gets loaded into small RAM areas on the CPU that are
> otherwise unused.
It is at least theoeretically possible that a microcode update might cause
an operation that's normally done very quickly (in dedicated hardware) to be
done by a slower path (microcode operations) to fix a bug in the dedicated
hardware that is very obscure and very unlikely to ever bother you. However,
I have never heard of even a single confirmed instance where this happened.
DS
A microcode update is used to correct errata in the processor, and the
facility is part of the architecture, as written in the manual. As Dave
pointed out, if the BIOS has the latest one, the OS does not need to do
anything.
We are working with Tigran closely, and we have provided the latest
updates to him very recently. He will try them out first, and then
publish the new updates for public consumption. Stay tuned.
Jun
>-----Original Message-----
>From: [email protected] [mailto:linux-kernel-
>[email protected]] On Behalf Of Justin Piszcz
>Sent: Thursday, March 18, 2004 8:41 AM
>To: [email protected]
>Subject: Linux Kernel Microcode Question
>
>The URL: http://www.urbanmyth.org/microcode/
>
>The microcode_ctl utility is a companion to the IA32 microcode driver
>written by Tigran Aivazian <[email protected]>. The utility has two
uses:
>
> * it decodes and sends new microcode to the kernel driver to be
>uploaded
>to Intel IA32 processors. (Pentium Pro, PII, PIII, Pentium 4, Celeron,
Xeon
>etc - all P6 and above, which does NOT include pentium classics)
> * it signals the kernel driver to release any buffers it may hold
>
>The microcode update is volatile and needs to be uploaded on each
system
>boot i.e. it doesn't reflash your cpu permanently, reboot and it
reverts
>back to the old microcode.
>
>My question is, what are the advantages vs disadvantages in updating
your
>CPU's microcode?
>
>Is it worth it?
>
>Does it matter what type of Intel CPU you have?
>
>Do some CPU's benefit more than others for microcode updates?
>
>I know RedHat distributions usually do this by default, but others do
not.
>
>Can anyone explain reasons to or not to update the CPU microcode?
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar - get it now!
>http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
Hi Justin,
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).
This is the advantage. There are no disadvantages. After the microcode
update has been loaded into the CPUs, the microcode driver can be removed
to save a tiny amount of memory that it takes:
# rmmod microcode
Yes, it does matter which Intel CPUs you have. The driver selects the
appropriate chunk of microcode for every CPU present on the system and
loads it accordingly. You may even have mixed CPUs (i.e. of different
kind) in an SMP system and this is handled automatically.
Kind regards
Tigran
On Thu, 18 Mar 2004, Justin Piszcz wrote:
> The URL: http://www.urbanmyth.org/microcode/
>
> The microcode_ctl utility is a companion to the IA32 microcode driver
> written by Tigran Aivazian <[email protected]>. The utility has two uses:
>
> * it decodes and sends new microcode to the kernel driver to be uploaded
> to Intel IA32 processors. (Pentium Pro, PII, PIII, Pentium 4, Celeron, Xeon
> etc - all P6 and above, which does NOT include pentium classics)
> * it signals the kernel driver to release any buffers it may hold
>
> The microcode update is volatile and needs to be uploaded on each system
> boot i.e. it doesn't reflash your cpu permanently, reboot and it reverts
> back to the old microcode.
>
> My question is, what are the advantages vs disadvantages in updating your
> CPU's microcode?
>
> Is it worth it?
>
> Does it matter what type of Intel CPU you have?
>
> Do some CPU's benefit more than others for microcode updates?
>
> I know RedHat distributions usually do this by default, but others do not.
>
> Can anyone explain reasons to or not to update the CPU microcode?
>
> _________________________________________________________________
> FREE pop-up blocking with the new MSN Toolbar ? get it now!
> http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Richard B. Johnson wrote:
> Review the stuff on http://www.x86.org. Even though it's slanted
> far to the left, there is some good information there.
??? I'm looking at that site, and it seems not to have been updated in
25 months... At any rate "today's headlines" are dated Feb 5, 2002.
Sounds like leaning to the obsolete.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Thu, 18 Mar 2004, Bill Davidsen wrote:
> Richard B. Johnson wrote:
>
> > Review the stuff on http://www.x86.org. Even though it's slanted
> > far to the left, there is some good information there.
>
> ??? I'm looking at that site, and it seems not to have been updated in
> 25 months... At any rate "today's headlines" are dated Feb 5, 2002.
> Sounds like leaning to the obsolete.
>
Yep. Seems to have been "acquired" by Dr. Dobbs Journal and is
on the way out. The last time I looked at it was probably about
two years ago. At that time, no reference to Dr. Dobbs.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, 18 Mar 2004, David Schwartz wrote:
> It is at least theoeretically possible that a microcode update might cause
> an operation that's normally done very quickly (in dedicated hardware) to be
> done by a slower path (microcode operations) to fix a bug in the dedicated
> hardware
Did you dream that up or did you read it somewhere? If the latter, where?
All operations are done by "dedicated hardware" and microcode DOES modify
that hardware, or rather the way instructions are "digested". So, applying
microcode doesn't make anything slower per se, it's just replacing one
code sequence with another code sequence. If a new code happens to be
slower than the old one then of course the result will be slower, but the
reverse is also true. When you fix a bug in a particular software why
should a bugfix be apriori slower than the original code? Think about it.
So please do not spread misinformation that applying microcode makes
something slower. If anything, it should make things faster, as long as
the guys at Intel are writing the correct (micro)code.
Kind regards
Tigran
> On Thu, 18 Mar 2004, David Schwartz wrote:
> > It is at least theoeretically possible that a microcode
> > update might cause
> > an operation that's normally done very quickly (in dedicated
> > hardware) to be
> > done by a slower path (microcode operations) to fix a bug in
> > the dedicated
> > hardware
> Did you dream that up or did you read it somewhere? If the latter, where?
Since you agree with me, I'm not sure I understand why it matters.
> All operations are done by "dedicated hardware" and microcode DOES modify
> that hardware, or rather the way instructions are "digested". So, applying
> microcode doesn't make anything slower per se, it's just replacing one
> code sequence with another code sequence. If a new code happens to be
> slower than the old one then of course the result will be slower, but the
> reverse is also true. When you fix a bug in a particular software why
> should a bugfix be apriori slower than the original code? Think about it.
I didn't say it would have to be slower. I said it might force an operation
to be done by a slower path. You seem to agree with me that the new code
could happen to be slower than the old one.
As for why a bugfix would be likely to be slower than the original code,
it's because of the limitations of the microcode update. The microcode
update can't change wiring, so if the problem is in wiring, then the
microcode would have to bypass that wiring. One would presume the wiring was
there for a reason -- to accelerate something.
> So please do not spread misinformation that applying microcode makes
> something slower. If anything, it should make things faster, as long as
> the guys at Intel are writing the correct (micro)code.
I'm simply saying that it's at least theoretically possible that a
microcode update might increase correctness at the expense of performance.
The only contrary position would be that such a thing is impossible. The
position I'm refuting is that there is not, even in theory, any downside to
performing a microcode update.
By the way, there is reason to believe that microcode updates can redirect
into microcode operations normally performed in hardware (though I know for
sure only that certain exceptions can be handled this way on at least one
Intel processor); however, I think it would be rather foolish to prefer
speed over correctness. I have also heard of microcode updates that
supposedly fixed performance problems.
DS
Hi David,
Yes, now I agree with you. Earlier I thought you were saying:
a) without microcode all operations are done "in hardware", i.e. faster
b) applying microcode somehow switches CPU to "software" mode and thus
makes it slower apriori (i.e. regardless of the actual _content_ of
microcode data).
Now you see that you meant something different and so there is no
disagreement there.
Kind regards
Tigran
On Fri, 19 Mar 2004, David Schwartz wrote:
>
>
> > On Thu, 18 Mar 2004, David Schwartz wrote:
> > > It is at least theoeretically possible that a microcode
> > > update might cause
> > > an operation that's normally done very quickly (in dedicated
> > > hardware) to be
> > > done by a slower path (microcode operations) to fix a bug in
> > > the dedicated
> > > hardware
>
> > Did you dream that up or did you read it somewhere? If the latter, where?
>
> Since you agree with me, I'm not sure I understand why it matters.
>
> > All operations are done by "dedicated hardware" and microcode DOES modify
> > that hardware, or rather the way instructions are "digested". So, applying
> > microcode doesn't make anything slower per se, it's just replacing one
> > code sequence with another code sequence. If a new code happens to be
> > slower than the old one then of course the result will be slower, but the
> > reverse is also true. When you fix a bug in a particular software why
> > should a bugfix be apriori slower than the original code? Think about it.
>
> I didn't say it would have to be slower. I said it might force an operation
> to be done by a slower path. You seem to agree with me that the new code
> could happen to be slower than the old one.
>
> As for why a bugfix would be likely to be slower than the original code,
> it's because of the limitations of the microcode update. The microcode
> update can't change wiring, so if the problem is in wiring, then the
> microcode would have to bypass that wiring. One would presume the wiring was
> there for a reason -- to accelerate something.
>
> > So please do not spread misinformation that applying microcode makes
> > something slower. If anything, it should make things faster, as long as
> > the guys at Intel are writing the correct (micro)code.
>
> I'm simply saying that it's at least theoretically possible that a
> microcode update might increase correctness at the expense of performance.
> The only contrary position would be that such a thing is impossible. The
> position I'm refuting is that there is not, even in theory, any downside to
> performing a microcode update.
>
> By the way, there is reason to believe that microcode updates can redirect
> into microcode operations normally performed in hardware (though I know for
> sure only that certain exceptions can be handled this way on at least one
> Intel processor); however, I think it would be rather foolish to prefer
> speed over correctness. I have also heard of microcode updates that
> supposedly fixed performance problems.
>
> DS
>
>
>
Tigran Aivazian wrote:
> On Thu, 18 Mar 2004, David Schwartz wrote:
>
>> It is at least theoeretically possible that a microcode update might cause
>>an operation that's normally done very quickly (in dedicated hardware) to be
>>done by a slower path (microcode operations) to fix a bug in the dedicated
>>hardware
>
>
> Did you dream that up or did you read it somewhere? If the latter, where?
>
> All operations are done by "dedicated hardware" and microcode DOES modify
> that hardware, or rather the way instructions are "digested". So, applying
> microcode doesn't make anything slower per se, it's just replacing one
> code sequence with another code sequence. If a new code happens to be
> slower than the old one then of course the result will be slower, but the
> reverse is also true. When you fix a bug in a particular software why
> should a bugfix be apriori slower than the original code? Think about it.
>
> So please do not spread misinformation that applying microcode makes
> something slower. If anything, it should make things faster, as long as
> the guys at Intel are writing the correct (micro)code.
I don't see anything wrong with what he said. As I understand it,
Pentium 4 CPUs don't use microcode for much of anything. If an
instruction which was done entirely in dedicated hardware was buggy, and
it's replaced by microcode, then it will most certainly be slower.
You seem to have missed where David used terms like "theoretically
possible" and "an operation".
On Mon, 22 Mar 2004, Timothy Miller wrote:
> I don't see anything wrong with what he said. As I understand it,
> Pentium 4 CPUs don't use microcode for much of anything. If an
> instruction which was done entirely in dedicated hardware was buggy, and
> it's replaced by microcode, then it will most certainly be slower.
>
> You seem to have missed where David used terms like "theoretically
> possible" and "an operation".
No, that is not what he said and that (what you say) is certainly wrong,
namely this bit:
If an instruction which was done entirely in dedicated hardware was
buggy, and it's replaced by microcode, then it will most certainly be
slower.
All instructions are done by means of microcode of some sort, i.e. the
instructions are "compiled" as they are executed into a more primitive
instruction set (called "microcode" or "u-code"). If a buggy instruction
(or rather the sequence of microcode which corresponds to it) is replaced
by a fixed version (i.e. by some other sequence of microcode) then there
is no reason to say that the result will "most certainly be slower". For
some bugs the fix runs faster than the broken code, for others it may be
slower --- there is no way to tell apriori that it will always be slower.
Do you understand now?
Kind regards
Tigran
Tigran Aivazian wrote:
> On Mon, 22 Mar 2004, Timothy Miller wrote:
>
>>I don't see anything wrong with what he said. As I understand it,
>>Pentium 4 CPUs don't use microcode for much of anything. If an
>>instruction which was done entirely in dedicated hardware was buggy, and
>>it's replaced by microcode, then it will most certainly be slower.
>>
>>You seem to have missed where David used terms like "theoretically
>>possible" and "an operation".
>
>
> No, that is not what he said and that (what you say) is certainly wrong,
> namely this bit:
>
> If an instruction which was done entirely in dedicated hardware was
> buggy, and it's replaced by microcode, then it will most certainly be
> slower.
>
> All instructions are done by means of microcode of some sort, i.e. the
> instructions are "compiled" as they are executed into a more primitive
> instruction set (called "microcode" or "u-code"). If a buggy instruction
> (or rather the sequence of microcode which corresponds to it) is replaced
> by a fixed version (i.e. by some other sequence of microcode) then there
> is no reason to say that the result will "most certainly be slower". For
> some bugs the fix runs faster than the broken code, for others it may be
> slower --- there is no way to tell apriori that it will always be slower.
>
> Do you understand now?
What you're describing is not microcode in the traditional sense.
Traditionally, microcode is a program store in the processor, and
machine instructions cause the CPU to start executing micro instructions
from that program store. The Pentium 4 doesn't operate that way.
On the other hand, it would make sense to have some of the instruction
decode being done using lookup tables, but the complexity of the x86
instruction set is such that it can't all be done that way.
On Mon, 22 Mar 2004, Timothy Miller wrote:
>
>
> Tigran Aivazian wrote:
> > On Thu, 18 Mar 2004, David Schwartz wrote:
> >
> >> It is at least theoeretically possible that a microcode update might cause
> >>an operation that's normally done very quickly (in dedicated hardware) to be
> >>done by a slower path (microcode operations) to fix a bug in the dedicated
> >>hardware
> >
> >
> > Did you dream that up or did you read it somewhere? If the latter, where?
> >
> > All operations are done by "dedicated hardware" and microcode DOES modify
> > that hardware, or rather the way instructions are "digested". So, applying
> > microcode doesn't make anything slower per se, it's just replacing one
> > code sequence with another code sequence. If a new code happens to be
> > slower than the old one then of course the result will be slower, but the
> > reverse is also true. When you fix a bug in a particular software why
> > should a bugfix be apriori slower than the original code? Think about it.
> >
> > So please do not spread misinformation that applying microcode makes
> > something slower. If anything, it should make things faster, as long as
> > the guys at Intel are writing the correct (micro)code.
>
> I don't see anything wrong with what he said. As I understand it,
> Pentium 4 CPUs don't use microcode for much of anything. If an
> instruction which was done entirely in dedicated hardware was buggy, and
> it's replaced by microcode, then it will most certainly be slower.
ALL instructions are performed by the microcode. If the microcode
that is loaded into the control-store upon reset is replaced by
microcode that is loaded later, why should it be slower? It is
possible that some control-sequence may be replaced with one that
takes fewer clocks, takes more clocks, or takes the same number of
clocks. If it takes the same number of clocks, there is no change.
If fewer, faster. If greater, slower. FYI, the WCS (Writable control-
store) goes back to Digital PDP-days (and VAXen). The CPU was a
board, not a chip. It was damn dumb upon power-up. A monitor program
in an 8085, loaded the microcode from a tape called the "console".
The WCS allows CPUs to be fixed permanently, if something is wrong,
with absolutely no negative trade-offs whatsoever.
>
> You seem to have missed where David used terms like "theoretically
> possible" and "an operation".
It is theoretically possible for me to win the Lottery tomorrow.
Since I haven't yet purchased a chance, it is unlikely.........
But chaos theory shows the probability is non-zero, even if I
don't purchase the chance. So, "theoretically" is one of those
words that can't be used to substantiate an argument.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Richard B. Johnson wrote:
>
> ALL instructions are performed by the microcode.
The Z80 had no microcode. It was completely hard-wired.
As I understand it, it's pretty much an ancient idea to do "everything"
by microcode. Only certain very complex instructions are done by microcode.
On the other hand, as I said before, it's not unreasonable for lookup
tables to be involved in instruction decoding.
On Mon, 22 Mar 2004, Timothy Miller wrote:
>
>
> Richard B. Johnson wrote:
>
> >
> > ALL instructions are performed by the microcode.
>
> The Z80 had no microcode. It was completely hard-wired.
>
Who was talking about the Z80? The WCS was added to the
Pentium line after the Patent issues were resolved.
Search on "writable control store" to see the many papers
and developments.
> As I understand it, it's pretty much an ancient idea to do "everything"
> by microcode. Only certain very complex instructions are done by microcode.
>
One of the "latest and greatest" such machines was made by Transmeta
(a.k.a. Linus` home when he first came to the US. The Crusoe, etc.,
could emulate just about anything because its microcode was deliberately
replaceable with even microcode that was architecturally different.
> On the other hand, as I said before, it's not unreasonable for lookup
> tables to be involved in instruction decoding.
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
> On Mon, 22 Mar 2004, Timothy Miller wrote:
> > I don't see anything wrong with what he said. As I understand it,
> > Pentium 4 CPUs don't use microcode for much of anything. If an
> > instruction which was done entirely in dedicated hardware was buggy,
> > and
> > it's replaced by microcode, then it will most certainly be slower.
> >
> > You seem to have missed where David used terms like "theoretically
> > possible" and "an operation".
> No, that is not what he said and that (what you say) is certainly
> wrong,
> namely this bit:
>
> If an instruction which was done entirely in dedicated hardware was
> buggy, and it's replaced by microcode, then it will most certainly be
> slower.
>
> All instructions are done by means of microcode of some sort, i.e. the
> instructions are "compiled" as they are executed into a more primitive
> instruction set (called "microcode" or "u-code"). If a buggy
> instruction
> (or rather the sequence of microcode which corresponds to it) is
> replaced
> by a fixed version (i.e. by some other sequence of microcode) then
> there
> is no reason to say that the result will "most certainly be slower".
> For
> some bugs the fix runs faster than the broken code, for others it may
> be
> slower --- there is no way to tell apriori that it will always be
> slower.
>
> Do you understand now?
You are using the word "instruction" to mean something different than
what I am using it to mean. I am using "instruction" to mean "the
smallest cohesive unit of operation". I do NOT mean "instruction" as
in "an operation coded by the programmer".
I am talking about the case where an "operation" performed in buggy
hardware is replaced by an "operation" performed in fixed microcode.
By the way, the recent Intel patent lawsuit had this exact same issue.
The word "instruction" can refer to *any* cohesive unit that performs
some logical function.
DS
> > Do you understand now?
>
> You are using the word "instruction" to mean something different than
> what I am using it to mean. I am using "instruction" to mean "the
> smallest cohesive unit of operation". I do NOT mean "instruction" as
> in "an operation coded by the programmer".
>
> I am talking about the case where an "operation" performed in buggy
> hardware is replaced by an "operation" performed in fixed microcode.
Using the word "operation" in this sense actually adds to the
confusion, because the term 'opcode' is, (or was), in common use for
"an operation coded by the programmer", which is not what you mean by
"operation" at all.
John.