Intel's System Management Mode
by Robert R. Collins
It might be tempting to assume that System Management Mode (SMM) on Intel's SL-enhanced microprocessors was nothing more than a marketing gimmick to sell a new feature that had already existed for ten years. A quick comparison of SMM and ICE mode (or the comparison of the undocumented instruction LOADALL to SMM's RSM instruction) could lead you to believe that SMM was nothing more than a legitimized ICE mode - and that RSM was nothing more than a documented form of the LOADALL instruction. However, as I have discovered, SMM was not a marketing gimmick, even though the similarities are striking. This column will be the first in a series discussing System Management Mode. This article will provide a prehistory of SMM oy comparing it to ICE mode.
In-Circuit Emulation: Prehistory of SMM
An in-circuit emulator (ICE) is used for low- level debugging. When an ICE is attached to a target system, a program may run at full speed, may be stopped and restarted, and can be single-stepped. An ICE has the ability to stop and restart any program from any execution mode - real, protected, and v86. An ICE even has the ability to debug a ROM BIOS before any software has been loaded, and set breakpoints anywhere in the ROM BIOS. The ICE has abilities that can't be achieved with any software-based debuggers. When program execution has been stopped, the ICE provides complete visibility of the microprocessor internals, undocumented descriptor structures (see http://www.x86.org/Productivity/DescriptorCache.html ), descriptor tables, paging tables, registers, memory, and more. An ICE is the ultimate debugger, and it carries a hefty $50,000 price tag.
There are two ways to enter ICE mode: internally and externally triggered. Internally, ICE mode is entered as the result of any debug breakpoint event. These events include debug register breakpoints, a TSS trap, the Trap Flag set, a write to any debug register (while DR7.GD=1), and the execution of the undocumented instruction ICEBP (see http://www.x86.org/secrets/opcodes/ICEBP.html ). All of these events normally result in a debug exception (Exception 01). When the ICE is connected, they may cause the debug exception, or they cause the ICE to halt emulation. This behavior is governed by an undocumented bit in DR7 (DR7.IR). (See Figure 1 for the location of DR7.IR, or http://www.x86.org/secrets/DR7.html for a description of all undocumented bits in DR7.) When DR7.IR=O, any debug exception will cause the INT-01 handler to be invoked. When DR7.IR=1, all debug exceptions will be redirected to the ICE; the ICE will halt execution and enter ICE mode. DR7.IR is automatically set by the ICE when debug breakpoints are specified, therefore no extra effort is needed to set this bit.
ICE mode is also triggered externally by asserting an undocumented microprocessor pin. On the standard Intel 80386 DX, asserting the undocumented pin at location B6 will cause the microprocessor to halt emulation and enter ICE mode. Typically, the ICE asserts this pin in response to some type of bus event. A bus event is an event that can only be observed from analyzing the microprocessor pins (the bus). The ICE can set breakpoints for many types of bus events, including, but not limited to:
Once the bus event occurs, the ICE hardware signals the microprocessor by asserting the undocumented "ICEBP" pin, which then causes the microprocessor to enter ICE mode.
Upon entrance to ICE mode, the microprocessor saves its entire state to an area of memory isolated from normal system memory. It is essential that enough of the processor state is saved to guarantee that a program can resume execution after leaving ICE mode. For this reason, the saved microprocessor state includes all program-visible registers (like EAX, EBX, CS, DS, and so on), internal data structures that can't be accessed by any x86 program (the descriptor cache registers), and system descriptors (GDT, IDT, LDT, and TR descriptors). Restoring all of these values is enough to guarantee that the microprocessor can be halted and restarted from any operating mode.
Hardware support of ICE mode is achieved through the implementation and use of a few undocumented microprocessor pins. ICE-mode memory isolation is achieved through the use of a few of these undocumented pins in cooperation with chipset support. Once in ICE mode, an output pin located at position C7 on the standard 80386 DX processor is asserted - much like the SMIACT# pin on SL-enhanced processors. Further memory isolation is achieved by having separate ADS#- and READY# pins for ICE mode. I termed these pins "IADS" and "IRDY" (my notes don't indicate whether they are active-high or active-low); they are located at positions E13 and F13, respectively. One effect of having separate ADS#- and READY# pins in ICE mode is bus-cycle transparency to a logic analyzer. When in ICE mode, the normal ADS# and READY# pins aren't asserted unless an ICE command is given to view memory or I/O. All code fetches and memory cycles to the supporting ICE program are performed using the IADS and IRDY pins. The logic analyzer doesn't recognize any bus cycles using these pins. Therefore, the microprocessor seems to disappear from the logic-analyzer trace when executing in ICE mode.
Once ICE mode begins, the processor immediately begins execution of the ICE- mode kernel. The microprocessor is operating in real mode, but all segment limits are set to 4 GB, and all segments are read/writable. The ICE stays in this mode, executing its own control software, until you command it to return to normal program execution. Once commanded, the ICE executes the undocumented LOAD- ALL instruction to restore the entire micro- processor state. (See http://www.x86.org/articles/loadall for a description of the LOADALL instruction.) LOADALL reads the table that was written at the entrance to ICE mode and restores the microprocessor to the exact state contained therein. Upon completion, the entire microprocessor state has been redefined and execution continues at the point indicated by the LOADALL table.
System Management Mode Overview
System Management Mode (SMM) is intended to be used for advanced power-management features and other operating-system-independent functions. The chipset is programmed to recognize many types of events and timeouts. When such an event occurs, the chipset asserts the SMI# input pin. At the next instruction boundary, the microprocessor saves its entire state and enters SMM.
As the microprocessor enters SMM, it asserts an output pin, SMIACT#. This pin serves notice to the chipset that the microprocessor is entering SMM. SMI# can be asserted at any time, during any process operating mode, except from within SMM itself. The chipset recognizes SMIACT# and redirects all subsequent memory cycles to a protected area of memory, reserved specifically for SMM. Immediately after receiving the SMI# input and asserting the SMIACT# output, the microprocessor begins to save its entire internal state to this protected memory area.
After the microprocessor state has been stored to memory, the special SMM handler begins to execute. The processor is in real mode, all segments have 4-GB limits, and all segments are read/writable. After the SMM code has executed, it's time to return to the previous operating environment. The program executes the RSM instruction to exit SMM. RSM reads the microprocessor state data from the state save map, and restores the entire microprocessor state. Like LOADALL, RSM performs virtually no checks on the data in the state save map. Upon completion of RSM, the entire microprocessor state has been redefined, and the previous program resumes execution right where it left off.
Comparing SMM and ICE Mode
When comparing ICE mode to System Management Mode, you could easily conclude that SMM was derived from ICE mode because their similarities are striking. Certainly, they have more similarities than differences. In reality, SMM appears to be both a subset and a superset of ICE mode. For the purposes of this comparison, I'll contrast 80386 ICE mode with Pentium SMM. Consider the following similarities:
There are also differences between the two modes:
When considering the reason for creating SMM, it's hard to ignore the slight differences between it and ICE mode. In many cases, it might seem that the differences represent an evolutionary change in ICE mode, and not a change in functional intentions. This might tend to reinforce the belief that SMM was a marketing gimmick, but such an assumption would be incorrect. Intel conceived of SMM as a means to perform functions, like power management or hardware emulation, independent of the current operating mode. Prior to SMM, it was impossible to perform such functions in a way that was independent of the operating system environment, or the operating mode of the microprocessor. SMM was seen as a means to address these problems. Once the SMM designers completed defining their requirements, they found that most of the microcode and hardware already existed in the microprocessor - as ICE mode. Naturally, they decided to leverage the existing facilities. This explains why SMM closely resembles ICE mode.
Others tried to follow Intel's lead. The IBM Blue Lightning and AMD 486 both introduced SMM. In their cases, however, they actually used their ICE mode and called it SMM. This design decision limited their abilities to debug SMM with an ICE. They could not use an ICE during SMM - whereas Intel could (as Intel ICE mode was still independent of SMM). AMD's use of the ICE microcode as SMM also lead to the SMM/ICE lawsuit from Intel - which Intel eventually won.
ICE mode and SMM are still evolving. ICE mode is now achieved through an entirely different mechanism. The new ICE mode is implemented via a special debug port and is now called probe mode (see http://www.x86.org/articles/probemd/ProbeMode.html for an overview of probe mode). The new ICE mode doesn't resemble SMM at all, doesn't use a state save map, or even execute any code of its own. SMM is also evolving. To address the limitations still inherent in SMM, Intel, Microsoft, and Toshiba are defining the successor to SMM and APM (Advanced Power Management). The new standard - ACPI (Advanced Configuration and Power Interface) - will address the current limitations, and result in a new software interface and modification to the current SMM (see http://www.teleport.com/-acpi/ for a description of ACPI).
In my next column, I will discuss many of the details of the Pentium SMM implementation and its associated secrets. You will learn what all of those "Reserved" areas in the state-save map are used for, and how the I/O restart feature can restart a string operation (REP OUTSB) from its beginning. In another future column, I'll discuss the caveats of SMM and how to avoid making mistakes when writing your own SMM handler.
Back to Dr. Dobb's Undocumented Corner home page