On 03/27/2018 12:58 PM, Nicholas Piggin wrote:
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.
Agree.
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.
Nick,
May be we should define sub-function usage. Also current API limits number of
arguments
and its type. may be we should have argument 2 as "void *" ?
something like :
s64 opal_debug(u32 debug_type, void *data, u64 dsize);
That way individual sub-function can parse/use based on its need.
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).
AFAIK secureboot won't block us here. It mostly blocks external entity (like
FSP/cronus) from
accessing host memory. (like they can't directly read, write to host memory,
SCOM operations
are restricted etc).
-Vasant
