Out-of-band SRESET

Ananth N Mavinakayanahalli ananth at linux.vnet.ibm.com
Fri Mar 17 16:25:15 AEDT 2017


On Thu, Mar 16, 2017 at 10:37:56AM -0500, Patrick Williams wrote:
> On Thu, Mar 16, 2017 at 01:32:52PM +0530, Ananth N Mavinakayanahalli wrote:
> > Hi,
> > 
> > One requirement from a OpenPOWER service point-of-view is to be able to
> > trigger an out-of-band SRESET on a unresponsive system. We can then have
> > the necessary plumbing in the host Linux kernel to either drop the
> > machine into a debugger or trigger a dump capture, if configured.
> > 
> > On P9, this would translate to a series of SCOM operations for the SBE
> > It would be good to have a REST API defined to cater to this specific
> > purpose.
> > 
> > The API should cater to:
> > - SRESET a core
> > - SRESET a chip
> > - SRESET all cores
> > 
> > Thoughts?
> > 
> > Regards,
> > Ananth
> > 
> 
> Ananth,
> 
> I understand the desire from your end with respect to debugging the
> host.  Is there something we can do to model this better from a REST
> perspective to make this less Power-specific?  Do other architectures
> also have a "send debug interrupt"?

Any option that says nmi for x86 can apply here, IMO.

> Do you need to SRESET targeting an SMT thread?  We will need to come up
> with some kind of identifier for sending the debug interrupts.

For starters, we will be using the SRESET as an unrecoverable entity --
option of last resort. The SRESET all cores will be the most used, but I
can envisage cases where we would need specific cores/threads to be
forced into xmon or such. While it is good to have the design to be able
to accommodate it, targeted SMT thread reset isn't a 'must have' to
begin with.

Ananth



More information about the openbmc mailing list