On Tue, 27 Mar 2018 12:42:32 +0530 Vasant Hegde <hegdevas...@linux.vnet.ibm.com> wrote:
> On 03/26/2018 08:39 PM, Nicholas Piggin wrote: > > xmon can be entered via sreset NMI (from a management sreset, or an > > NMI IPI), which can interrupt OPAL. Add checks to xmon to see if pc > > or sp are within OPAL memory, and if so, then use OPAL_DEBUG to > > print the opal stack and return the Linux stack, which can then be > > dumped by xmon > > Nick, > > > OPAL uses FSP/cronus interface for many of debug interface (like OPAL assert, > getting opal console, triggering FSP R/R etc). May be in future we may add > new > debug capability. It would be good to ensure an API could accommodate them, or at least not get in the way. > Once secureboot is enabled none of these interface work and we have limited > debug > capability. > > Here you are using very generic API name (OPAL_DEBUG). May be we should have > generic > interface (exported via debugfs?) here rather than SRESET specific one. OPAL_DEBUG here actually uses the sub-function OPAL_DEBUG_DUMP_STACK (1), but I didn't bring that constant across from skiboot which I should have. But I don't think this is SRESET specific. If Linux has any way to get an r1 for a CPU in OPAL, then it can use this function. If it does not, then it simply can't use it. I haven't really followed what's happening with secure boot, but presumably we can still get NMIs (at least machine check, even if all system reset sources are suppressed). > > > > The OPAL side of this, with sample xmon output is here: > > > > https://lists.ozlabs.org/pipermail/skiboot/2018-March/010856.html > > > > This could be plumed into the oops printing code as well. Thanks, Nick
