I've been meaning to come back and paint a more complete picture for a while now, but have been busy with school, sorry.
Now that it's spring break, I have a brief moment to post some answers to questions I've been having, and I think you people might want in.
If all you have to do is write to the MSR to overclock a CPU, and leave it at that, that doesn't leave room in the picture for things like PLLs and pinmods.
So how are PLLs and pinmods related to the MSR and overclocking?
PLLs: The processor has no mechanism by which it can keep a beat. It can't just look at the MSR and say "Ohp, gotta go 3.0 GHz. Ok. Imma goin' 3.0 GHz." It has to receive a constant stream of rhythm-keeping from something: the PLL. There is a crystal and a chip that together form a PLL, which stands for "Phase Locked Loop". The processor sends whatever is written at a certain spot in the MSR to this chip. That message sent from the processor to the PLL chip tells the chip what frequency to produce. The processor is connected to this rhythm made by the PLL and goes however fast that rhythm is going, which forms the clock speed of the processor.
Of course that is overly simplified, because there is the multiplier, the front side bus (FSB) speed, and other clocks going on, but that shows the connection between MSR and PLL.
It's my guess that different PLL chips speak different "languages", meaning one chip abides by one set of codes and meanings thereof, and another chip abides by another set of codes and meanings thereof. So if you want to set the FSB to, say, 400 MHz, you have to know the code that means "400 MHz" for your particular PLL. So I'm guessing that the alphanumric code printed on the PLL chip tells you what language your PLL speaks, so you know how to communicate "go 400 MHz, please" to your PLL, which, in it's langauage, is what you write to the MSR for the processor to send to the PLL. So you can't know what to write to the MSR until you know the language of your PLL.
I'm also guessing that if, say, the FSB speed and the speed of your SATA controller are "locked" together, this is due to both being physically connected to the same PLL, to go along with the theme of debunking the myth that the BIOS has any power over such things once the OS is loaded. (The alternative I'm trying to negate would be to theorize that the BIOS isn't providing you the option to clock them separetly, and thus the limitation is a purely software one in the BIOS (the BIOS is software). I'm saying, no, I bet it's some physical limitation.)
Pinmods: You can connect certain pins of your processor to make it go faster. The way I've heard this explained is that the processor reports to the BIOS upon startup what its default speed is. By doing a pinmod, you alter what the processor reports as its default speed.
So that would mean that the BIOS simply writes to the MSR the PLL code equivalent for whatever speed was reported by the processor upon startup. This code is then sent to the PLL chip by the processor like normal, which of course then spits out a steady beat of the requested frequency at the CPU, making it go that fast. If you don't know your PLLs "language", you might have to take this route, because appearently the BIOS does know the language. However, it would still be up to your BIOS whether it wants to use the default speed reported by the processor, or use some other speed it's programmed to use, such as the speed you told it to set it to, residing in the CMOS or NVRAM.
Here's a little more info about PLLs. If you really what to learn about them, Google and Wikipedia search about PLLs.
The PLL governing you CPU is, of course, on the motherboard. Go ahead and take a peak, you people with clear-sided cases. If you're looking for a naked crystal stuck onto your motherboard, you'll probably be looking for quite a while. The naked crystal isn't showing. It has a shell over it, kind of like a turtle or limpet. The "shell" is shiny and metalic, and is shaped like a rectange with half a circle stuck on each end of the rectangle, like a running track you'd find around a football field (U.S football, not soccer). Supposedly there is a chip nearby the crystal, but on my motherboard, the crystal seems to be out all by itself, and I trust that somehow it's connected to a chip somewhere on the motherboard.
Some crystals have the ability to output regularly spaced pulses of electricity over time given an input voltage. This is how a quartz watch works (the quartz is the crystal). In a quartz watch, every so many pulses from the quartz is a second, every 60 seconds is a minute, and so on. A similar idea is at play with the PLL buisness, though not exactly. The PLLs I've read about split a given wave into equally sized pieces, rather than produce a steady rhthym all on their own. In other words, they multiply the input frequency by a whole number. That's how the multiplier works. The wave keeps going around and around the PLL system until it's near perfectly cut up into even peices. If it gets ahead of itself, it pulls back, and if it gets behind, it pushes forward. By going around enough times, it comes out pretty good. So "Phase" refering to what it does with waves, and "loop" refering to going around and around. It's a Phase Locked Loop, a PLL.
On the shiny housing of the crystal is an alphanumberic code. Usually this is almost impossible to read. I found out that you're actually supposed to read the alphanumeric code printed on the chip next to the crystal instead. It's a lot easier to read. But can you find the chip if its no where near the crystal?
Ok, some side ramblings about MSR stuff:
The MSR seems to be used for other things, too. I read about the MSR being used to turn hardware-assisted virtualization on and off. That is determined by one bit in the MSR. There is another bit in the MSR that determines whether you can flip the bit that turns hardware-assisted virtualization on and off. If that bit is flipped to not let you turn hardware-assisted virtualization on and off, that bit is stuck in the locked position until a power cycle clears everything. So if the firmware on startup flips this bit into the "locked" position whilst hardware-assisted virtualization is off, you'll never get to use hardware-assisted virtualization until you modify the firmware itself or whatever setting of the firmware that is telling it to do that, to not do that.
So again, the firmware is gone once the operating system is loaded (it's not being executed on the processor), but the firmware has left behind an effect. So it creates the illusion, often times, that the operating system is running on top of the firmware.
Also, since hardware is initialized by the firmware, hardware can "remember" things from the BIOS or EFI, potentially furthering the illusion.
And I have a hunch that the mode of the processor (real, protected, etc) is determined by bits in the MSR.
Which reminds me of another question I had: "If you're still in real mode, can you flip the hardware-assisted virtualization locking bit back?" Because if that's true, one could simply write a Grub module to do the trick, rather than having to "hack firmware/ settings". You're still in real mode when you're in Grub.
Oh - and I have to wonder about the people who have been saying (to my poll question) that they found it very easy find out how to overclock a cpu in Linux. What software are they using? Did they just have an easy time finding the software? What great searching skill and technique do they have that I don't? I would like to know these secrets.
Ok. Now time for sources/ nice links.
Support that the MSR is in fact what controls the voltage and clockspeed of the processor (see second paragraph of "Background"):http://www.thinkwiki.org/wiki/Pentium_M_undervolting_and_underclocking
And 7th block of writing within the first post here: http://www.olpcnews.com/forum/index.php?topic=2389.0
And see the next couple links.
You can tell from this conversation that the MSR and clockspeed are related (Ctrl+F for "msr"):http://forum.notebookreview.com/acer/480992-acer-laptop-phoenix-bios-bios-mod-request-112.html
Support that you write to the MSR, then the processor sends what you wrote to the MSR to the PLL, which creates the requested rhthym, which
directly controls (it is) the CPU clock speed:
Page 18 of this: ftp://download.intel.com/design/mobile/datashts/31407804.pdf
A quote from the above "Voltage and Frequency Selection is software controlled by writing to processor MSRs"
Another: "and the PLL then locks to the new frequency"
There are other Intel documents like the above on that talk about PLLs, MSRs, and clock speeds.
Also, I found some source code that suggests a connection between the MSR and PLL:http://dev.laptop.org/~rsmith/LinuxBIOSv2/src/northbridge/amd/gx2/pll_reset.c
That cpu-overclocking pinmods work by the processor reporting its default speed to the BIOS upon startup:
Check second post here: http://forums.anandtech.com/showthread.php?t=2182822
Check 10th post here: http://www.techspot.com/vb/topic108719.html
*Note: don't let the Google ad throw off your
counting. The ad doesn't count as a post.
Lists a bunch of overclocking-related acrynyms and their meanings. (don't forget the "next page" button at the bottom):http://www.hardwaresecrets.com/article/Understanding-All-Voltage-Configurations-from-the-Motherboard/995/1
When I give an example of the FSB speed and SATA controller speed being locked together, that notion came from here:http://www.hardwaresecrets.com/article/How-to-Overclock-a-Socket-775-Pentium-4/198
Here's some pictures of PLLs and getting info off them for overclocking:http://www.zuneboards.com/forums/showthread.php?t=18125
MSR and hardware-assisted virtualization and those two bits:
One bit turns hardware-assisted virtualization on an off, while the other might keep you from flicking that bit:http://www.linux-kvm.org/page/Enable_VT-X_on_Mac_Pro_%28Early_2008%29
Look under "The Problem" for "The way is works is that it has 2 flags..."
Hardware-assisted virtualization and firmware hacking:http://marcansoft.com/blog/2009/06/enabling-intel-vt-on-the-aspire-8930g/
Also, I plan on seeing if I can test this overclocking software in Linux in QEMU whilst QEMU is emulating a processor. Haven't had time to do it yet,
but I did have time to try and test lm_sensors in QEMU (for checking core temp - an important tool whilst overclocking). Turns out that QEMU doesn't
emulate such sensors.
P.S. If you find out about anything concerning any of this, or another overclocking tool for Linux, post it!
P.P.S. If this works, it will blow your mind: http://www.opengl.org/news/comments/vrizer_linux_library_to_create_stereoscopic_output_for_any_opengl_based_gam/