From: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org,
Stewart Smith <stewart@linux.vnet.ibm.com>,
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL
Date: Wed, 28 Mar 2018 22:39:58 +0530 [thread overview]
Message-ID: <ddc6bb66-9a9c-0ce8-2f49-669c5f124cf1@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180327172856.252ec56b@roar.ozlabs.ibm.com>
On 03/27/2018 12:58 PM, Nicholas Piggin wrote:
> On Tue, 27 Mar 2018 12:42:32 +0530
> Vasant Hegde <hegdevasant@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
prev parent reply other threads:[~2018-03-28 17:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-26 15:09 [RFC PATCH] powerpc/xmon: Use OPAL_DEBUG to debug srest in OPAL Nicholas Piggin
2018-03-27 7:12 ` Vasant Hegde
2018-03-27 7:28 ` Nicholas Piggin
2018-03-28 17:09 ` Vasant Hegde [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddc6bb66-9a9c-0ce8-2f49-669c5f124cf1@linux.vnet.ibm.com \
--to=hegdevasant@linux.vnet.ibm.com \
--cc=ananth@in.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mahesh@linux.vnet.ibm.com \
--cc=npiggin@gmail.com \
--cc=stewart@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).