After finding this:
http://www.mjmwired.net/kernel/Documentation/cpu-freq/pcc-cpufreq.txt, I was reminded of the need to dispel an illusion.
Now take all this with a grain of salt. I'm not infallible, but I try to be as accurate as I can. I give what I have found/ figured out so far. And this forum does have an edit button, lucky for me : ). Please post anything you believe to be a correction.
Many things out there create the illusion that the BIOS or other system firmware is underneath the operating system, and that the operating system runs on top of the system firmware. In fact, some diagrams straight-up show this. Some times, the illusion gets so thorough as to be tempting to think the system firmware is a hypervisor, actually executing the OS, parallel to how the OS runs programs. Chief examples of the latter are booting a DOS floppy image with memdisk (which is thought of as causing the BIOS to emulate a floppy drive, as if the BIOS were a hypervisor, like VirtualBox or something) and booting an iso with grub4DOS by creating a drive mapping in memory pointing to the iso and then chainloading that drive mapping, which might be thought of as causing the BIOS to emulate a CD drive.
And it is particularly easy to think that the system firmware is running at the same time as your OS. It doesn't, unless you're doing something pretty wild. And no, overclocking isn't wild enough.
Sometimes it looks like the system firmware has more access to hardware than the OS does. This is not true because they execute on the same processor.
Following the above link, you will be taken to a webpage discussing one particular method of overclocking: have the operating system communicate to the system firmware (BIOS, EFI, whatever), and then have the system firmware do the overclocking.
If you're not on your toes, that method of overclocking might be in the number of things that support the aforementioned illusion.
Remember: the operating system and the system firmware are executed on _the_same_processor, the CPU, therefore anything that system firmware does, the operating system can do (and probably better, because it has more storage space for code). This is unique amongst firmwares, because all other firmware is executed on a separate processor. Your hard drive, optical drives, mouse, keyboard, monitor, card reader, joystick, graphics card, sound card, SATA controllers, USB controllers and every piece of hardware that executes firmware (except the motherboard) has its own processor for executing its firmware. Since the operating system is not executing on any of those processors, the operating system can't directly do anything with those pieces of hardware, and the only way to use all this hardware is by communicating to the firmware running on the devices. For example, the SCSI command set is a way the operating system can communicate with the firmware running on the hard drive to read from and write to that hard drive.
But such communication with the system firmware is unnecessary because the operating system is already running on the CPU, which is the processor the system firmware runs on.
Note that the operating system can't replace any of those "local" firmwares, because the OS is not running on any of the processors controlling those pieces of hardware. In fact, it's physically impossible for the OS to run on any of those processors.
But the system firmware and the OS _do_ run on the same processor, and therefore, the operating system _can_, in theory, replace the system firmware once the system is booted into the OS.
Anyways, I think your typical example of overclocking the CPU that involves the OS communicating to firmware simply has the firmware write to the MSR rather than having the OS write to the MSR.
For the curious, let me break down the illusion (consider the above my actual post, and the below an extra).
The system firmware (BIOS, EFI, whatever) actually sits in memory. All RAM is memory, but not all memory is RAM. Some of the memory addresses actually point to a flash storage chip soldered to the motherboard, which holds the system firmware.
So in a simple world, if you knew the memory address range that pointed to the system firmware chip, you could make an image of your firmware simply by reading from memory and writing what you read to a file. In Linux (and all Unix-like OSes, such as Mac OS X), this can be done with dd in terminal, setting your input file (abbreviated as "if") to /dev/mem (the abstraction file created by the OS that represents all memory), using the skip parameter to start where you need to, specifying how much to copy with bs (block size) and count, and setting "of" (output file) to the path and name of the new file you want dd to create as dd writes the system firmware to file.
QEMU is such a groovy computer emulator that you can actually specify the BIOS (or EFI) image you wish for it to use as its firmware in the virtual machine. So in theory, you could then execute your system firmware image in an emulator, but due to the differences between your real hardware and the hardware QEMU emulates, this probably won't work.
And, similarly, in a simple world, you could switch the "if" and "of" parameters of dd to write a firmware image to your system firmware chip, flashing your system firmware.
But we don't live in a simple world. Often, during startup, the system firmware (or maybe only the routines component of it, talked about later) is actually copied from the chip to RAM for faster access. This is called shadow RAM. I think at this point the CPU does a little black magic and actually reroutes those memory addresses to point to those locations in RAM, and they no longer point to the chip, but I might be wrong on that one. Another thing that convolutes the matter is that the firmware is often compressed on the chip, and is decompressed as it is copied into RAM.
Anyways, as far as I know, almost all processors, whether it be your brand-new Ivy Bridge Intel processor; the 25-cent processor in your wrist-watch; the processor in your mouse executing its firmware; the processor of your optical drive performing witchcraft with the crazy firmware needed summon out processed sectors from a very strange analog medium; any one of the many processors in an automobile; a processor in a router executing its firmware; the processor in your digitalized washing machine, coffee maker, touch-screen hair dryer; or whatever, are either physically designed or programmed (pure hardware processors are physically designed to do this, and processors that use microcode are possibly programmed to do this) to, upon power up, immediately being executing whatever is at a certain location in memory.
This certain spot in memory is where the firmware is. Your CPU is no exception and starts executing the system firmware upon power-up. The firmware does the Power On Self Test (POST), as well as hardware initialization.
After doing the POST and hardware initialization, the system firmware hopefully then passes control to a bootloader, which hopefully then passes control to an operating system.
But there's really 2 parts to the BIOS. Part of it is the part the processor goes right to and executes upon startup. The other part is a bunch of programs chillin' out in memory, just sitting there at your disposal. Since there is a BIOS standard, it is known what each one does, and I'm guessing you could probably, in theory, execute any one of them right out of memory as a program running in an operating system, but that's not how they are traditionally executed.
These BIOS programs chillin' in memory (called BIOS routines) are traditionally executed by interrupts. When a program tells a processor to do an interrupt (each interrupt has a number), the processor pauses whatever it's doing, does the program on that interrupt (a BIOS program chillin' in memory, in this example), then resumes what it was doing before. So never is the system firmware executed at the same time as the OS. You can also see that the OS isn't running inside the system firmware. One is not on top of or below the other.
DOS hardly, if ever, communicates to hardware. Rather, it calls BIOS programs in memory by interrupts to communicate to hardware for it. When you boot an Acronis True Image CD, it communicates to the CD drive by BIOS interrupts. So you can fool DOS into thinking there is a floppy drive present that really isn't by modifying the program in memory that DOS uses to communicate to floppy drives. Let's say you don't have a floppy drive. You can boot a bootable floppy image with DOS on it with memdisk because memdisk does some stuff to what's in memory so that when DOS makes that interrupt call to talk to a floppy drive, it is communicating to the program memdisk put in memory (rather than the original BIOS routine), which reads from a copy of the floppy image that was copied into memory by memdisk, and this impostor routine sends back the data at DOS in an identical fashion to how the normal BIOS routine would send data back at DOS from an actual floppy drive. And DOS doesn't know any different, because it never bothers to look at the hardware itself.
I believe something similar is at play when you use grub4DOS to boot an iso image of the Acronis True Image CD.
Note that never for a moment did you emulate hardware. The moment the OS actually looks at hardware for itself, the illusion from this pho-emulation is dispelled. Here's a fun example you can do. Make an iso image of a WinXP installation disc (I think Win98 works too. If WinXP doesn't work, try Win98), and boot it with grub4DOS by doing that mem, hook, chainload stuff. It will work for a while, but when you hit a certain point, it will blue-screen! This is because for a while it's using (a) BIOS routine(s) to communicate with the non-existent CD drive, then, at a certain point, it starts to look at hardware for itself, and poof! The non-existent CD drive from which the installer is running disappears. Uh-oh, blue screen time.
So note that this pho-emulation works only with operating systems that never look at hardware themselves _and_ this pho-emulation is also dependent that there be BIOS routines in memory present. If these routines aren't present, such as on a pure EFI machine, this won't fly. This makes this method useable only for very few applications. DOS and Acronis are the only two I personally know of that will work with this.
Notice the design flaw of making an OS that depends on system firmware. For one, the OS is dependent on a certain type of firmware (as in BIOS vs EFI vs whatever). DOS and Acronis can't run on a pure EFI machine. Because Macs have a BIOS compatibility module that their EFI can load, DOS and Acronis _can_ run on Macs, but Acronis can't image any drive that has any partitioning scheme other than MBR (that I know of), at least the version I have, another design flaw of Acronis, thus it still wouldn't be able to image your Mac's GPT schemed hard drive.
Any limitation that the firmware has, your OS would have. For example, DOS can't use GPT drives because it never reads and writes to the hard drive. Rather it has BIOS routines do that for it. BIOS can't do GPT. Therefore DOS can't do GPT.
If the system firmware has a bug, then that sucks if you use the system firmware instead of your own code.
Also, system firmware routines are executed on interrupt, abruptly bringing the entire operating system and all programs it is executing to a halt while everyone waits for this one program to get done executing.
To quote Linus Torvalds, the task of the system firmware (BIOS, EFI, whatever) is "just load the OS and get the hell out of there". So methods of overclocking the CPU in Linux that have Linux itself write to the MSR are more in line with his beliefs than running a program in Linux that calls system firmware to overclock for it. As far as I know, Linux isn't supposed to execute any system firmware routines, but apparently it does sometimes: http://kerneltrap.org/node/6884. And just look at Xorg. Why is EFI such an issue for Xorg, and why does loading a partial BIOS dump into memory fix it? Because it uses a BIOS routine. You could, however, argue that Xorg isn't technically a part of Linux, even though, as far as I know, is in the Linux kernel.
So when the computer powers on and goes sys firmware > bootloader > OS, the sys firmware is no longer being executed once control has been passed to the bootloader. Only at the very beginning is the system firmware being executed without having been called via interrupt. Now that control has been passed to the bootloader, the bootloader may choose to ask the processor to execute a sys firmware routine via interrupt. If the bootloader calls such an interrupt, the bootloader is then paused, that routine is executed, then execution of the bootloader is resumed. Likewise once the bootloader passes control to the OS.
So never is the system firmware ran at the same time as the OS (unless there's a such thing as an OS that runs a firmware routine out of memory as a program under the OS, like how Linux runs FireFox. I don't think this exists.).
And most assuredly, the system firmware never executes the OS, unless you have system firmware that really is a hypervisor, which exists in some embedded systems, sometimes even with a processor dedicated to the task of creating the emulated hardware platform.
And unless your system firmware is a hypervisor, your OS has just as much access to the hardware as the firmware does, thus the firmware is not "underneath" the OS, because they run on the same CPU. However, some OSes choose to have firmware communicate to hardware for it, even though the OS could have communicated to hardware.
Any diagram showing the OS on top of the system firmware, where the system firmware is not a hypervisor, is doing so from the perspective that the OS is having the system firmware talk to the hardware for it, thus in that situation the system firmware is behaviorally closer to the hardware, even thought the OS has just as much access to the hardware.
And be aware of pho-emulation of hardware. Memdisk and grub4DOS do not emulate hardware. If you wish to actually emulate a CD drive and boot an iso from that, you need to use a hypervisor such as the Xen Hypervisor, creating a virtual machine in "Hardware-assisted or Full Virtualization (HVM)" mode (which uses QEMU - QEMU scores two for two), rather than in parvirtualization mode. Thus with the Xen Hypervisor, you could boot an iso off your thumb drive and actually be emulating a CD drive. Just note that you'll be running on Xen's (QEMU's) emulated hardware platform, not your real hardware. Thus booting into a Windows installation disc iso via the Xen Hypervisor and going through the installer will result in an installation of Windows configured for Xen's (QEMU's) emulated hardware, not your real hardware. If you boot a Linux installation iso with Xen and install Linux, you'll be fine because Linux doesn't get specific to one set of hardware, unless maybe you start doing stuff with graphics drivers.Edited by SpawnHappyJake - 5/10/12 at 11:44pm
