Hi,
Czernobyl wrote:
° example 1: some extremely & unpredictably long, typically running for days or even weeks, iterative number theoretic calculations running entirely on integer registers, _including_ r/e/SP, so, no stack possible, few if any memory accesses (even cache accesses are slooow...) - but wouldn't it be convenient to still be able to interrupt the calculation, look at its state, and restart it afterwards? _No stack_, hence no interrupts possible (besides taking time away from the main problem, taking interrupts would pollute the cache, hence take even more time). Of course polling of e.g. the keyboard ports is out of the question. SMI, by pressing a button or (on my SiS chipsets) a hotkey, solves the problem elegantly.
Um. If you're worried about things like IRQs messing up cache contents (which is bizarre to begin with); put your IRQ handler and its stack in an "uncached" area (either by messing with MTTRs or the "cache disable" flag in page tables). Not only would this be far more portable, it'd be easier and also faster (because the CPU has to save/load a lot of additional state when entering/leaving SMM, switch CPU modes, etc).
Czernobyl wrote:
° Another example of (non OS) utility of SMIs : to easily make "flashrom" work on boards where the (e.g. Intel) chipset & BIOS would normally trap and reject attempts at accessing the flash w/o knowing "secret" handshakes, including GPIOs and the like, which are difficult to "reverse engineer". Much easier is to hack a quick and dirty RSM instruction in place of the SMI handler's first instruction (depending on what the mobo uses SMIs for, it might be slightly more complicated, especially on portables, but still easier than tracking the GPIOs :=)
Instead of spending ages to find a way to accidentally brick your motherboard before throwing it in the trash; why not just throw the motherboard in the trash without wasting that time?
Cheers,
Brendan