From: Nicholas Piggin <npiggin@gmail.com>
To: Alistair Popple <alistair@popple.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, <skiboot@lists.ozlabs.org>
Subject: Re: [PATCH] powerpc/powernv: implement NMI IPI with OPAL_SIGNAL_SYSTEM_RESET
Date: Fri, 3 Feb 2017 16:21:54 +1000 [thread overview]
Message-ID: <20170203162154.08b85ff0@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <3306162.5sCMYZyWl3@new-mexico>
On Fri, 03 Feb 2017 17:00:19 +1100
Alistair Popple <alistair@popple.id.au> wrote:
> On Fri, 3 Feb 2017 03:20:48 PM Nicholas Piggin wrote:
> > On Fri, 3 Feb 2017 00:25:11 +1000
> > Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > > This goes with the previous NMI IPI series, and a new version of
> > > Alistair's opal API I posted to the skiboot list.
> >
> > And here is the incremental bit that is required for Alistair's
> > hardware implementation to work.
> >
> > If the opal broacast call fails with OPAL_PARTIAL, then we designate
> > a bouncer CPU on another core to send NMI IPIs back to our sibling
> > threads.
> >
> > Probably needs more discussion and testing about how to detect and
> > handle failure cases and future compatibility for different types of
> > restrictions, but at least it works in mambo.
>
> Looking at the Mambo implementation you recently posted I couldn't see
> where OPAL_PARTIAL was returned. So I guess you have other Skiboot
> patches to test this path using Mambo? I'm wondering because they
> could be useful for testing the skiboot HW side as well...
Oh I just did it all on the Linux side, just forced it to always
do bounce rather than try broadcast first, I was lazy. But we'll
make mambo match the hardware implementation as far as possible
once you've got something.
> > Of course the other option rather than doing this in Linux is call
> > into opal in the system reset handler and have it do the bouncing.
> > Something to consider before we finalise the API.
>
> That might not be such a bad idea. OPAL could queue up the threads it
> couldn't reset and then wait until opal_sreset_complete() is called
> from an eligible thread to reset the ones it couldn't do in the
> original call.
Yeah, IIRC we thought it might have been harder to do in firmware,
but that may not be the case.
It may not be a bad idea in general for opal to have a token
available to hook system resets too.
> I might try prototyping something like this when I get some time. One
> issue would be if there is only a single core in the system, but
> that's unlikely and I think that's probably something we can't support
> in any case as cores can't sreset threads on the same core, at least
> on P8.
Yes on powernv it would be unusual, except maybe mambo where we
can make it work.
Thanks,
Nick
prev parent reply other threads:[~2017-02-03 6:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 14:25 [PATCH] powerpc/powernv: implement NMI IPI with OPAL_SIGNAL_SYSTEM_RESET Nicholas Piggin
2017-02-03 5:20 ` Nicholas Piggin
2017-02-03 6:00 ` Alistair Popple
2017-02-03 6:21 ` Nicholas Piggin [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=20170203162154.08b85ff0@roar.ozlabs.ibm.com \
--to=npiggin@gmail.com \
--cc=alistair@popple.id.au \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=skiboot@lists.ozlabs.org \
/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).