How is microcode loaded to processor?

memory cpu computer-architecture

12,967

Solution 1

I read that microcode is loaded in the processor on each reboot.

The BIOS can issue a microcode update during boot. So can the operating system. Frequently these updates are required, especially with later Intel CPUs.

It resides on flash memory and when the machine is booted, it gets copied to the CPU. Or in the case of Linux, the OS itself has the microcode copy for the processor. But how does the microcode get copied to the processor?

Modern Intel and CPUs have a mechanism called "Model Specific Registers", and special CPU instructions to read (RDMSR) and write to them (WRMSR). While these registers affect CPU settings, writing to a specific one with the address of the new microcode tells the CPU to read a region of memory and apply over the existing microcode.

All data moves in a computer by the consent of the CPU. CPU is given instructions in machine language. As microcode is imperative for execution of these machine language instructions, so without the microcode being present in the processor, how the instruction for accessing the flash memory and doing the consequent operations are done by CPU?

There is always a microcode. The mechanism above updates the microcode. Intel/AMD don't really publish specifics on how it works, they only provide an update mechanism. Obviously somehow it is copying a ROM microcode to some sort of CPU internal memory. But there is some microcode there when the CPU starts. Some recent Intel and possibly AMD CPUs won't work reliably after boot without a microcode update done by the BIOS but evidently they will function well enough to perform an initial microcode update.

Does this mean that hard-wired non-microcoded instructions copy the microcode in real mode?

The initial microcode setup is done internally by the CPU and no instructions are executed to achieve that. It's setup before the first CPU instruction is executed.

To update the BIOS the appropriate RDMSR and WRMSR instructions must be executed.

Reference: "This instruction must be executed at privilege level 0 or in real-address mode; otherwise, a general protection exception #GP(0) will be generated." If it's not executed in real mode it must be done in ring 0 or kernel mode. You can update the microcode anytime.

Solution 2

Modern CPUs come with complete microcode already installed. This microcode resides in a special ROM area on the CPU itself and cannot be changed/erased. Thus, the CPU can function out-of-the-box.

The system BIOS and/or Operating System can then initiate the loading of a microcode update into the CPU. Such an update is not a complete microcode, but rather a small patch to address bugs. The CPU contains a small area of volatile RAM for this purpose.

A useful reference: https://www.dcddcc.com/pubs/paper_microcode.pdf

Solution 3

The microcode update is a patch only to the existing CPU microcode which is burned into ROM permanently. The CPU has a permanent ROM and a patch RAM which can contain new code. There is also a table of "match" values that is in RAM. This table has an entry for every patchable part of the ROM. When the CPU executes a patchable instruction, it checks this table. If there is an entry, then it uses the code in RAM. If it has the default value, then it jumps to ROM. So, to patch the CPU it is necessary to upload the new code to RAM and then modify entries in the match table appropriately. The procedure for doing this is roughly as follows:

Clear EAX, read the current processor signature using CPUID, and load the matching microcode update into kernel memory.
Clear EAX and EBX, and read the current microcode revision using the RDMSR instruction from the revision match specific register.
Write the memory address of the microcode update using the WRMSR instruction to the update match specific register.
Read the new microcode revision, and return success if it matches that of the update. Otherwise, return failure.

In Linux-based operating systems, this process is done on boot by a specific kernel module called "microcode". You can read the source code for this module to see the exact process.

Note that the patch files have a documented header, but the patch data itself, the actual code, is encrypted by a secret key which is hard-coded into the processor. Unless you know this key, you would have no way of writing your own patches.

Solution 4

The question is ill-formulated. There are many "microcodes" in modern x86/IA64 CPU, and there is a difference between "microcode patch" and microcode.

The microcode in its classic understanding (as step-by-step elements of execution of long CPU instructions) is almost certainly en-carved in silicon, as there is no reason to keep bugs unfixed along many generations of CPU, when new silicon/RTL is compiled with every new manufacturing node.

However, all recent CPUs have several internal units that are controlled by independent microprocessors that are embedded inside the x86 CPU chip.

Most notable/known is so-called "P-unit", a processor that controls dynamic power management of the CPU. As core frequencies went up and leakage went up with further miniaturization of CPU transistors, the only way to keep power in reasonable limit is by aggressive clock throttling and dynamic power gating. The problem is that the CPU can execute infinite varieties of software codes, and each reaches a certain peak of power consumption. Some patterns of "power viruses" may not be known at the moment when CPU was finalized for retail, and some parameters of managing algorithms must be corrected. This is done via dedicated "microcode patches".

There are several more microprocessors of this sort that control other CPU blocks like graphics and memory.

The details of patching process are top secret, to prevent malicious interference. Here is some hacker's report on the attempt to reverse engineer the mechanism.

In short, the x86 architecture microcode is not loaded in modern CPUs, but microcodes for various auxiliary embedded microprocessors can have patches.

View more solutions

12,967

Kraken

Updated on September 18, 2022

Comments

Kraken over 1 year

I read that microcode is loaded in the processor on each reboot. It resides on flash memory and when the machine is booted, it gets copied to the CPU. Or in the case of Linux, the OS itself has the microcode copy for the processor. But how does the microcode get copied to the processor? All data moves in a computer by the consent of the CPU. CPU is given instructions in machine language. As microcode is imperative for execution of these machine language instructions, so without the microcode being present in the processor, how the instruction for accessing the flash memory and doing the consequent operations are done by CPU? Does this mean that hard-wired non-microcoded instructions copy the microcode in real mode?
- sawdust almost 9 years
  
  "I read that microcode is loaded in the processor on each reboot." -- Your source/premise in not correct.
- misha256 almost 9 years
  
  @sawdust CPU microcode does get loaded at every cold boot, either by the system BIOS or OS early in its boot process.
- sawdust almost 9 years
  
  @misha256 -- "CPU microcode does get loaded at every cold boot," -- That implies a chicken-or-egg conundrum. Are you confusing the (possible) update of microcode with (an alleged) loading of microcode? There's a world of difference between the two.
- misha256 almost 9 years
  
  @sawdust Good point. I need to be more clear. Modern CPUs come with hard-wired microcode. Microcode Updates are then applied by the BIOS or OS as required. The CPU contains a small amount of volatile "patch" RAM for this purpose.
- Kraken almost 9 years
  
  @misha256 do -- Hard-wired as in "made up of logic and etched on the circuitry" or as in "present on permanent memory, ready to be executed."
- misha256 almost 9 years
  
  @Kraken You're being a bit too pedantic. ROM programming is a form of hard-wiring. And microcode is just another conceptual abstraction layer (of many). You can put microcode into RAM, ROM, or "etch it directly on the circuitry" if you want. It's still microcode though, regardless of how you physically implement it in the CPU.
- oldmud0 almost 9 years
  
  I still don't understand why this is a bad question. I never even knew what microcode was in relation to a conventional CPU.
Kraken almost 9 years

Hard-wired as in "made up of logic and etched on the circuitry" or as in "present on permanent memory, ready to be executed." -- Because if they are hardwired, they should not be labeled microcode anymore.
sawdust almost 9 years

"Modern CPUs have hard-wired microcode" -- That's an oxymoron, since it's "hardwired" versus microcoded (aka microprogrammed). A better descriptor might be "built-in".
Kraken almost 9 years

What? "Built in" microcode, that is present on a non volatile memory inside CPU. Or a built-in hardwired combinatorial-logic system?
Kraken almost 9 years

@misha256 there some simple instructions that are directly executed by hardware?
misha256 almost 9 years

@Kraken Like any complex system, CPU design consists of a number of layers. But in the end, all the layers are considered, as a whole, to be hardware. For example, when designing a CPU, you might separate things out like this: Logic/gates-layer --> Micro-operations layer --> Micro-instructions layer --> Micro-code layer, --> Machine-code layer. These layers are conceptual rather than physical. Once you have your design, you are free to implement these layers how you like. In the end, everything ends up hard-wired in silicon. Including the microcode.
misha256 almost 9 years

@Kraken I found something for you: en.wikipedia.org/wiki/Micro-operation.
sawdust almost 9 years

@Kraken "What? "Built in" microcode, ... a built-in hardwired combinatorial-logic system?" -- Now you're just being argumentative. The "built-in" adjective was to differentiate that microcode with the "updated" microcode. Also the classic conceptualization for microcode (as I learned in college) was that it resided in the "control store", which implies some sort of memory device. See A Brief History of Microprogramming
sawdust almost 9 years

@Ramhound -- You seem to have problems following the discussion. I offered constructive criticism to misha256, and the response was an appropriate correction to the answer. Kraken's response to that critique was a ridiculous recombination of terms.
Ramhound almost 9 years

@sawdust - You win; I withdraw my feedback; do what you want;
Kraken almost 7 years

Thanks for reading through my ill-formulated, year(s)-old question in the first place. Your answer is very precise and full of insight. +1. Thanks again.