System Management Mode: Difference between revisions

m
Reverted edits by Atie (talk) to last revision by Superleaf1995
[unchecked revision][unchecked revision]
(Rewrite with more detail - needs an expert's input)
m (Reverted edits by Atie (talk) to last revision by Superleaf1995)
 
(8 intermediate revisions by 5 users not shown)
Line 1:
[[System Management Mode]] (SMM) is an operating mode on x86 and x86-64 processors, intended for use by firmwareFirmware/BIOS to perform low-level system management operations while an OS is running.
 
== The role of SMM ==
Line 5:
 
SMM is intended to be completely transparent to the OS. When the system enters SMM, the firmware preserves the state of the CPU in a region of RAM designated as "SMRAM". During SMM the firmware performs low-level management operations like changing fan speeds, checking thermal zones, adjusting the CPU speed, etc. Before leaving SMM, the firmware restores the state of the CPU from SMRAM. From the perspective of the OS, those low-level management operations are happening atomically and automatically in the background.
 
 
== Triggering SMM ==
SMM is triggered through a System Management Interrupt (SMI), a signal sent from the [[chipset]] to the CPU. During platform initialization, the firmware configures the chipset to cause a System Management Interrupt for various events that the firmware developer would like the firmware to be made aware of. The firmwaresfirmware also designates the region of RAM that should be used as SMRAM and specifies where the CPU should jump when an SMI occurs. During operation, the chipset detects the configured events and signals an SMI, triggering the CPU to enter SMM by jumping to the SMM entry point. The OS has no way of knowing when the chipset might signal an SMI and cannot "catch" System Management Interrupts like other interrupts. SMIs are not routed through the [[IVT]]/[[IDT]].
 
An OS ''can'' ask the chipset to signal an SMI, although the handling of the SMI will still be transparent. This is performed by writing to a particular [[port]] (determined via [[ACPI]]). If the OS asks the chipset to signal an SMI and there is no reason for an SMI to be triggered at that particular moment, the firmware will not have much to do and the OS will regain control almost immediately.
 
An OS ''can'' ask the chipset to signal an SMI, although the handling of the SMI will still be transparent. This is performed by writing to a particular [[Port IO|port]] (determined via [[ACPI]]). If the OS asks the chipset to signal an SMI and there is no reason for an SMI to be triggered at that particular moment, the firmware will not have much to do and the OS will regain control almost immediately.
 
== SMM and ACPI ==
SMM predates [[ACPI]]. Without ACPI, it makes sense that the firmware would want to stay resident in memory even once an OS is running, because the OS may not have drivers for all of the thermal sensors, fans, and CPU performance settings that are available on that particular motherboard/chipset/CPU combination. With ACPI, however, the firmware stores [[AML]] code for the OS to interpret and execute; that AML tells the OS how to handle all those things. Theoretically, this means that SMM is not nearly as critical on a modern system as on a pre-ACPI system. However, at boot time the firmware has no way of knowing whether or not the OS includes a complete ACPI implementation or whether the OS is willing to take responsibility to managing power, thermal properties, and CPU performance. So by default, the firmware will still use SMM to handle all those things itself.
 
If, however, at some point the OS indicates to firmware that it ''does'' have a complete ACPI implementation, the firmware will stop performing those low-level management operations and will expect the OS to perform them instead. Even once the OS takes over, the chipset will still occasionally signal SMIs and the CPU will enter SMM, but the firmware will not have very much to do.
Line 21 ⟶ 19:
 
A simple example of SMM and ACPI is the power button. Pressing the power button causes the chipset to signal an SMI, sending the CPU into SMM and jumping to the SMM entry point. The firmware determines that the power button was pressed. By default, before the OS takes over low-level system management responsibilities, the firmware will handle the event by telling the chipset to tell the power switching component of the motherboard to turn off, and the system powers off immediately. If, however, the OS has indicated that ''it'' will handle low-level system management responsibilities, the firmware ignores the button press and updates the ACPI structures in memory to note that the event occurred. The OS can detect the event by examining the ACPI structures and perform any clean-up operations (like saving files) before ''it'' tells the chipset to tell the power switching component of the motherboard to turn off.
 
 
== Transparency ==
TODO - write a bit about how SMM implements its transparent behavior, SMRAM, the lock bits in the MMU, etc.
 
 
== What can I do with system management mode? ==
Line 31 ⟶ 27:
 
[[Category:X86]] [[Category:Operating Modes]]
[[de:System_Management_Mode]]
Anonymous user