Below are some tools for confirming and characterizing SMIs presented in a suggested order of use. Counting SMIs with Cyclictest is a good place to start because it is a good idea to first confirm that SMIs are happening on a system before investigating the possibility that they are causing latencies.
The concepts of SMI and SMM are specific to x86, but some of the techniques and tools mentioned above can be used to debug similar firmware or hardware issues on other architectures.
It is important to note that there are intentionally only a few vague suggestions about how long it should take to handle an SMI in the pages linked above. This is because, in the case of SMI handling, the definition of “too long” depends on the application's timing requirements. More specifically, the maximum number of SMIs, the maximum frequency at which SMIs can occur, and the maximum amount of time it can take to handle SMIs, all depend on the application's requirements. One application might be able to handle several SMIs that take 10-15 us to resolve whereas those times may be way too long for another application. Additionally, an SMI related latency of over 100 us is generally bad, but again the timing requirements of certain applications could allow for such latencies. So, a knowledge of the system's deadline requirements is absolutely necessary for interpreting the results of the suggested tests.
In order to help confirm the results from the analysis facilitated by the tools mentioned above, here are a few tasks that are often completed in system management mode:
It is more likely that an apparently unexplainable latency in a situation or in code related to one of these topics is caused by an SMI.