On Fri, Jun 30, 2017 at 4:28 PM Nico Huber nico.h@gmx.de wrote:
Sounds really doable, but I'm a bit confused here, maybe because I didn't look at SMM handlers for some time. Did you evaluate if you need SMM at all? I just thought if you add board specific code to the kernel, why would you have to do anything in SMM? In the case of ACPI, most interrupts are already directly routed to the kernel (as SCI instead of SMI).
That would be optimal -- just turn it off. We're seeing a problem with linux startup, while booting no smm enabled, where Linux really wants to do that OSL nonsense via SMI for ACPI. Can we really configure hardware such that an SMI is impossible, and will Linux continue to work if we do?
I like your idea a lot -- just do whatever it takes to make SMM interrupts turn into normal SCI -- I just don't know for sure it's possible to make it happen. But I'll look.
The remaining problem is the "security" offered by having an SMI gatekeeper on the flash. Given the history of such "security" approaches, I suspect we're better off without them. BUT, there is concern that if we don't use these approaches, there are scenarios where flash gets written by the wrong people.
Also, if you are going to reimplement the vendor ACPI tables, why not write kernel-native drivers? ACPI is just a weird OS-independent way of writing drivers.
I agree with you here, but we can only kill one dragon at a time.
We ran supercomputers at LANL for years, up until 2010 or so, with no SMM and ACPI and all was well. I've never quite figured out what problem SMI and ACPI solved that could not have been solved better in other ways.
ron