[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:
<snip>
> >
> > 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.
Regards,
Alistair
> Thanks,
> Nick
More information about the Skiboot
mailing list