Linux Foundation Wiki

project collaboration site

User Tools

Site Tools


realtime:documentation:howto:debugging:smi-latency:smi

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
realtime:documentation:howto:debugging:smi-latency:smi [2018/07/10 14:45]
ebugden Add description of system management interrupts
realtime:documentation:howto:debugging:smi-latency:smi [2018/08/03 11:14] (current)
ebugden Add link to MSR documentation
Line 1: Line 1:
 ====== System management interrupt (SMI) ====== ====== System management interrupt (SMI) ======
  
-System management interrupts are high priority unmaskable hardware interrupts which cause the CPU to immediately suspend all other activities, including the operating system, and go into a special execution mode called system management mode (SMM). Once the system is in SMM, the interrupt is handled by firmware code.+System management interrupts are high priority unmaskable hardware interrupts which cause the CPU to immediately suspend all other activities, including the operating system, and go into a special execution mode called ​[[realtime:​documentation:​howto:​debugging:​smi-latency:​smm|system management mode]] (SMM)  ([[https://​software.intel.com/​en-us/​articles/​intel-sdm|Intel SDM]], Vol.1 3.1). Once the system is in SMM, the interrupt is handled by firmware code.
  
-The operating system has absolutely no control over when SMIs will happen or how long the CPU will subsequently stay in system management mode. In fact, the operating system is not even aware of the transitions to and from SMM. Thankfully, there are some ways to confirm whether or not an SMI has happened. For example, Intel x86 CPUs from after around 2008 (as of the Nehalem microarchitecture) have a model specific register (MSR) that counts the number of SMIs that have occurred in a system.+----
  
-The concepts of SMI and SMM are specific to x86, but similar high privilege processor modes exist on some other architectures. For example, on ARM there is a Secure Monitor mode that manages the switches between the Secure and Non-secure processor states ​(ARM Documentation).+The operating system has absolutely no control over when SMIs will happen or how long the CPU will subsequently stay in system management mode. In fact, the operating system is not even aware of the transitions to and from SMM. Thankfully, there are some ways to confirm whether or not an SMI has happened. For example, Intel x86 CPUs from after around 2008 (as of the Nehalem microarchitecture) have a model specific register (MSR) that counts the number of SMIs that have occurred in a system ([[https://​software.intel.com/​en-us/​articles/​intel-sdm|Intel SDM]], Vol.4 Table 2-14). 
 + 
 +The concepts of SMI and SMM are specific to x86, but similar high privilege processor modes exist on some other architectures. For example, on ARM there is a [[https://​developer.arm.com/​docs/​ddi0301/​latest/​programmers-model/​secure-world-and-non-secure-world-operation-with-trustzone/​how-the-secure-model-works|Secure Monitor mode]] that manages the switches between the Secure and Non-secure processor states.
realtime/documentation/howto/debugging/smi-latency/smi.1531233921.txt.gz · Last modified: 2018/07/10 14:45 by ebugden