From: Leonardo Bras <leobras.c@gmail.com>
To: Paul Mackerras <paulus@ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: peterz@infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
Alexios Zavras <alexios.zavras@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Enrico Weigelt <info@metux.net>
Subject: Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash
Date: Tue, 12 May 2020 00:48:28 -0300 [thread overview]
Message-ID: <f967cab2b473406ee6427f40109c85d46b438271.camel@gmail.com> (raw)
In-Reply-To: <20200409002726.GA5135@blackberry>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hello Paul, thanks for the reply!
On Thu, 2020-04-09 at 10:27 +1000, Paul Mackerras wrote:
> On Wed, Apr 08, 2020 at 10:21:29PM +1000, Michael Ellerman wrote:
> > We should be able to just allocate the rtas_args on the stack, it's only
> > ~80 odd bytes. And then we can use rtas_call_unlocked() which doesn't
> > take the global lock.
>
> Do we instantiate a 64-bit RTAS these days, or is it still 32-bit?
According to LoPAR, we can use instantiate-rtas or instantiate-rtas-64.
It looks like we do instantiate-rtas today (grep pointed only to
prom_instantiate_rtas()).
> In the old days we had to make sure the RTAS argument buffer was
> below the 4GB point. If that's still necessary then perhaps putting
> rtas_args inside the PACA would be the way to go.
Yes, we still need to make sure of this. I will study more about PACA
and try to implement that way.
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 862 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Leonardo Bras <leobras.c@gmail.com>
To: Paul Mackerras <paulus@ozlabs.org>,
Michael Ellerman <mpe@ellerman.id.au>
Cc: Enrico Weigelt <info@metux.net>,
peterz@infradead.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, Nicholas Piggin <npiggin@gmail.com>,
Alexios Zavras <alexios.zavras@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash
Date: Tue, 12 May 2020 00:48:28 -0300 [thread overview]
Message-ID: <f967cab2b473406ee6427f40109c85d46b438271.camel@gmail.com> (raw)
In-Reply-To: <20200409002726.GA5135@blackberry>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hello Paul, thanks for the reply!
On Thu, 2020-04-09 at 10:27 +1000, Paul Mackerras wrote:
> On Wed, Apr 08, 2020 at 10:21:29PM +1000, Michael Ellerman wrote:
> > We should be able to just allocate the rtas_args on the stack, it's only
> > ~80 odd bytes. And then we can use rtas_call_unlocked() which doesn't
> > take the global lock.
>
> Do we instantiate a 64-bit RTAS these days, or is it still 32-bit?
According to LoPAR, we can use instantiate-rtas or instantiate-rtas-64.
It looks like we do instantiate-rtas today (grep pointed only to
prom_instantiate_rtas()).
> In the old days we had to make sure the RTAS argument buffer was
> below the 4GB point. If that's still necessary then perhaps putting
> rtas_args inside the PACA would be the way to go.
Yes, we still need to make sure of this. I will study more about PACA
and try to implement that way.
Best regards,
Leonardo Bras
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 862 bytes --]
next prev parent reply other threads:[~2020-05-12 3:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 0:00 [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash Leonardo Bras
2020-04-01 3:07 ` kbuild test robot
2020-04-01 3:07 ` kbuild test robot
2020-04-01 3:07 ` kbuild test robot
2020-04-01 9:26 ` Peter Zijlstra
2020-04-01 9:26 ` Peter Zijlstra
2020-04-01 23:53 ` Leonardo Bras
2020-04-01 23:53 ` Leonardo Bras
2020-04-02 11:28 ` Michael Ellerman
2020-04-03 0:37 ` Leonardo Bras
2020-04-03 6:41 ` Nicholas Piggin
2020-04-03 6:41 ` Nicholas Piggin
2020-04-08 2:36 ` Leonardo Bras
2020-04-08 2:36 ` Leonardo Bras
2020-04-08 12:21 ` Michael Ellerman
2020-04-08 12:21 ` Michael Ellerman
2020-04-08 16:48 ` Leonardo Bras
2020-04-08 16:48 ` Leonardo Bras
2020-04-08 18:00 ` Leonardo Bras
2020-04-08 18:00 ` Leonardo Bras
2020-04-08 22:55 ` Leonardo Bras
2020-04-09 0:27 ` Paul Mackerras
2020-04-09 0:27 ` Paul Mackerras
2020-05-12 3:48 ` Leonardo Bras [this message]
2020-05-12 3:48 ` Leonardo Bras
2020-05-12 10:42 ` Michael Ellerman
2020-05-12 10:42 ` Michael Ellerman
2020-04-06 18:46 ` Leonardo Bras
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=f967cab2b473406ee6427f40109c85d46b438271.camel@gmail.com \
--to=leobras.c@gmail.com \
--cc=alexios.zavras@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=info@metux.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulus@ozlabs.org \
--cc=peterz@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.