From: Leonardo Bras <leobras.c@gmail.com>
To: Nicholas Piggin <npiggin@gmail.com>,
Allison Randal <allison@lohutok.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"Gautham R. Shenoy" <ego@linux.vnet.ibm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nadav Amit <namit@vmware.com>,
Nathan Lynch <nathanl@linux.ibm.com>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] powerpc/rtas: Implement reentrant rtas call
Date: Sat, 16 May 2020 01:08:24 -0300 [thread overview]
Message-ID: <97dcf4d840871ae3ce87e3f3c2efbdb709d66db5.camel@gmail.com> (raw)
In-Reply-To: <1589525800.2asfsw2zlu.astroid@bobo.none>
Hello Nick,
On Fri, 2020-05-15 at 17:30 +1000, Nicholas Piggin wrote:
> Excerpts from Leonardo Bras's message of May 15, 2020 9:51 am:
> > Implement rtas_call_reentrant() for reentrant rtas-calls:
> > "ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
> >
> > On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
> > items 2 and 3 say:
> >
> > 2 - For the PowerPC External Interrupt option: The * call must be
> > reentrant to the number of processors on the platform.
> > 3 - For the PowerPC External Interrupt option: The * argument call
> > buffer for each simultaneous call must be physically unique.
> >
> > So, these rtas-calls can be called in a lockless way, if using
> > a different buffer for each cpu doing such rtas call.
>
> What about rtas_call_unlocked? Do the callers need to take the rtas
> lock?
>
> Machine checks must call ibm,nmi-interlock too, which we really don't
> want to take a lock for either. Hopefully that's in a class of its own
> and we can essentially ignore with respect to other rtas calls.
>
> The spec is pretty vague too :(
>
> "The ibm,get-xive call must be reentrant to the number of processors on
> the platform."
>
> This suggests ibm,get-xive can be called concurrently by multiple
> processors. It doesn't say anything about being re-entrant against any
> of the other re-entrant calls. Maybe that could be reasonably assumed,
> but I don't know if it's reasonable to assume it can be called
> concurrently with a *non-reentrant* call, is it?
This was discussed on a previous version of the patchset:
https://lore.kernel.org/linuxppc-dev/875zcy2v8o.fsf@linux.ibm.com/
He checked with partition firmware development and these calls can be
used concurrently with arbitrary other RTAS calls.
>
> > For this, it was suggested to add the buffer (struct rtas_args)
> > in the PACA struct, so each cpu can have it's own buffer.
>
> You can't do this, paca is not limited to RTAS_INSTANTIATE_MAX.
> Which is good, because I didn't want you to add another 88 bytes to the
> paca :) Can you make it a pointer and allocate it separately? Check
> the slb_shadow allocation, you could use a similar pattern.
Sure, I will send the next version with this change.
>
> The other option would be to have just one more rtas args, and have the
> crashing CPU always that. That would skirt the re-entrancy issue -- the
> concurrency is only ever a last resort. Would be a bit tricker though.
It seems a good idea, but I would like to try the previous alternative
first.
> Thanks,
> Nick
Thank you Nick!
prev parent reply other threads:[~2020-05-16 4:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 23:51 [PATCH v4 0/2] Implement reentrant rtas call Leonardo Bras
2020-05-14 23:51 ` [PATCH v4 1/2] powerpc/rtas: Move type/struct definitions from rtas.h into rtas-types.h Leonardo Bras
2020-05-14 23:51 ` [PATCH v4 2/2] powerpc/rtas: Implement reentrant rtas call Leonardo Bras
2020-05-15 7:30 ` Nicholas Piggin
2020-05-16 4:08 ` Leonardo Bras [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=97dcf4d840871ae3ce87e3f3c2efbdb709d66db5.camel@gmail.com \
--to=leobras.c@gmail.com \
--cc=allison@lohutok.net \
--cc=benh@kernel.crashing.org \
--cc=ego@linux.vnet.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=namit@vmware.com \
--cc=nathanl@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
/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).