• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 10 subscribers
  • Views 1327 views
  • Users 0 members are here
Options
Related
How was your experience today?

Are ARM-based Linux servers susceptible to System Management Interrupts (SMIs)? I am able to track them on Intel- and AMD- based servers.

Chuck N

On Intel-based server I can get the SMI cound by reading at the appropriate offset in /dev/cpu/%u/msr
On AMD-based server I can get it from the appropriate performance counter
What do I do on ARM processors for the same functionality, or are SMIs not a part of the ARM ecosystem?

The reason for asking is that on x86 processors, SMIs interrupt processing from the O.S.'s perspective, and I need to be able to monitor these events.

A bit of background can be found at https://wiki.linuxfoundation.org/realtime/documentation/howto/debugging/smi-latency/smi

  • 0

    I don't know the detail, but... As your link says SMI & SMM are x86 specific. For Arm there are different systems. 

    This old StackExchange answer may shed some light, as might searching for Secure Monitor on developer.arm.com and also learning about TrustZone etc. Your answer is likely to need more detail about the generation & type of processor (A/M/R series, v7/v8/v9?), and what additional features are added, including by the actual silicon vendor, not just Arm. 

  • 0

    While Arm v8+ machines don't have SMI. They do have exceptions/interrupts that can be routed to EL3, where generally you will find Trusted Firmware A. But AFAIK there isn't a standard way to retrieve the number of times an interrupt/exception has fired to EL3. Really, for what I think your doing it should be tracked per core in the system as well, because unlike SMM mode which acts to stop the entire machine an EL3 interrupt will generally only consume a single core during processing. So it is a far less intrusive operation. Much of this is going to be platform dependent with some platforms never doing anything in EL3/etc while some platforms will be doing a lot more heavyweight RAS/sEL0/etc processing. So, check to see if your platform's TFA is public, look at this document TFA interrupt-framework-design. Then you might be able to add a field to intr_type_descs to count the number of times an interrupt has fired from here. Then add a SMCC call/etc to retrieve the values.

    Another idea might be to look at the TFA PMU support and an an appropriate counter supported by your platform.