[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87mu6dbfjm.fsf@mpe.ellerman.id.au>
Date: Tue, 12 May 2020 20:42:21 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Paul Mackerras <paulus@...abs.org>
Cc: Leonardo Bras <leonardo@...ux.ibm.com>,
Nicholas Piggin <npiggin@...il.com>,
Alexios Zavras <alexios.zavras@...el.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Christophe Leroy <christophe.leroy@....fr>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Enrico Weigelt <info@...ux.net>, peterz@...radead.org,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v3 1/1] ppc/crash: Reset spinlocks during crash
Paul Mackerras <paulus@...abs.org> writes:
> 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?
No, yes.
> In the old days we had to make sure the RTAS argument buffer was
> below the 4GB point.
Yes you're right, that's still true.
I was thinking we were on the emergency stack, but we may not be.
> If that's still necessary then perhaps putting rtas_args inside the
> PACA would be the way to go.
Yeah I guess. Allocating a struct within the RMO for each CPU is not
that simple vs just putting it in the paca.
cheers
Powered by blists - more mailing lists