[Skiboot] [PATCH] core/fast-reboot.c: Add sreset opal call

Alistair Popple alistair at popple.id.au
Tue Nov 22 10:59:58 AEDT 2016

On Mon, 21 Nov 2016 07:01:42 PM Nicholas Piggin wrote:


> > 
> > Currently active threads on the currently executing core cannot be
> > sreset as a thread cannot ram other threads on the same core. This
> > means the caller will need to reset these threads to make the call
> > from a different core.
> Hi Alistair,
> Great stuff. Do you see any way to lift this restriction in future,
> or do we need to make this part of the API? We should be able to make
> the Linux powernv platform code have NMI'ed cores bounce the NMI
> back to our sibling threads without too much work or changes to the
> platform independent NMI code.

The restriction comes from the hardware, which means one way or another we 
need to bounce around to different cores to do a complete reset, either in 
skiboot or Linux.

It would be possible to do it in skiboot by ramming one of the other cores to 
a trampoline in skiboot which would then go and reset the remaining cores 
before returning them to Linux, however this would create a couple of 
complications (eg. when all of the cores are sleeping) so I think it would be 
simpler to deal with this restriction in Linux.

> So this should be fine, but we should ensure the API has a way to
> communicate this type of failure (that requires an NMI bounce from
> another core, as opposed to some other failure). Did you have any
> thoughts there?

Right. Currently the call will return OPAL_PARTIAL when it couldn't reset all 
of the requested cores which I admit may be somewhat vague. We could I suppose 
have an API where we ask OPAL to reset all the cores and it returns a list of 
the ones which were successfully reset. This would be slightly more efficient 
than resetting one core at a time as we wouldn't need to continually quiesce 
other threads but I'd be interested in your thoughts here as well.



> Thanks,
> Nick

More information about the Skiboot mailing list