| |||||||||||||
The realtime preemption mini-summitThe realtime preemption mini-summitPosted Sep 28, 2009 23:15 UTC (Mon) by niv (subscriber, #8656)Parent article: The realtime preemption mini-summit
Jon, thanks for the excellent write-up as usual.
"Some hardware allows SMIs to be disabled, but it's never clear what the consequences of doing so might be; if the CPU melts into a puddle of silicon, the resulting latencies will be even worse than before".
Just to elaborate on the above, and to clear up any doubt on the issue, as we (IBM) have actually done work to remediate SMIs - we are pretty confident that our CPUs will not melt into a puddle, and we officially support on select platforms IBM premium real-time mode which allows us to do this safely (don't try this at home :)).
In all seriousness, though, we have open-sourced the work that Keith Mannthey has done (he talked about this at LPC this past week, and we'll have his slides up on the LPC website shortly) and I imagine it would be of interest to others.
(Log in to post comments)
The realtime preemption mini-summit Posted Sep 29, 2009 9:23 UTC (Tue) by nix (subscriber, #2304) [Link]
It's a bit unfortunate that the ability to have the OS actually control the machine is relegated to a "premium real-time mode" on "select platforms". *Everything* should work like this.
The only tolerable use for SMIs IMNSHO is emergency thermal control, i.e. keeping the hardware safe...
The realtime preemption mini-summit Posted Oct 4, 2009 13:51 UTC (Sun) by dvhart (guest, #19636) [Link]
There are other less known uses for SMIs that are an unfortunately reality of our world. Fixing hardware bugs is one. A buggy instruction for instance can get emulated under an SMI. It would be wonderful if those things never existed, but in practice, that just isn't the case.
The realtime preemption mini-summit Posted Oct 5, 2009 19:10 UTC (Mon) by bdonlan (guest, #51264) [Link]
Buggy instructions can also be fixed in the kernel, however, and at least then you know about them. While this may be a bit unfeasable for Windows, there should be some kind of switch Linux can use to disable the SMI handling, and just pass things to the normal #UD handler. If you then include hooks for any operations needing emulation at the same time as loading new microcode to disable the hardware support, no problem.
|
|||||||||||||