[RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL
npiggin at gmail.com
Tue Mar 27 18:28:56 AEDT 2018
On Tue, 27 Mar 2018 12:42:32 +0530
Vasant Hegde <hegdevasant at 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
> 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
> 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.
More information about the Linuxppc-dev