[PATCH v3 28/32] powerpc/64s: interrupt implement exit logic in C

Michael Ellerman mpe at ellerman.id.au
Fri Mar 19 22:44:53 AEDT 2021


Nicholas Piggin <npiggin at gmail.com> writes:
> Excerpts from Christophe Leroy's message of March 15, 2021 11:41 pm:
>> 
>> Le 25/02/2020 à 18:35, Nicholas Piggin a écrit :
>>> Implement the bulk of interrupt return logic in C. The asm return code
>>> must handle a few cases: restoring full GPRs, and emulating stack store.
>>> 
>>> The stack store emulation is significantly simplfied, rather than creating
>>> a new return frame and switching to that before performing the store, it
>>> uses the PACA to keep a scratch register around to perform thestore.
>>> 
>>> The asm return code is moved into 64e for now. The new logic has made
>>> allowance for 64e, but I don't have a full environment that works well
>>> to test it, and even booting in emulated qemu is not great for stress
>>> testing. 64e shouldn't be too far off working with this, given a bit
>>> more testing and auditing of the logic.
>>> 
>>> This is slightly faster on a POWER9 (page fault speed increases about
>>> 1.1%), probably due to reduced mtmsrd.
>>> 
>>> Signed-off-by: Nicholas Piggin <npiggin at gmail.com>
>>> Signed-off-by: Michal Suchanek <msuchanek at suse.de>
>>> ---
>> 
>> ...
>> 
>>> +notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs, unsigned long msr)
>>> +{
>> 
>> ...
>> 
>>> +
>>> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
>>> +	local_paca->tm_scratch = regs->msr;
>>> +#endif
>> 
>> Could we define a helper for that in asm/tm.h, that voids when CONFIG_PPC_TRANSACTIONAL_MEM is not 
>> selected ?
>
> Yeah I wanted to do something about that. I don't know what it's used 
> for here. I guess it saves the return MSR so if that causes a crash then 
> the next oops would see it, but I wonder if we can just get that from 
> SRR1 + program check error codes, or if there is something we can't
> reconstruct from there.

In the cases when you need it, you can't reconstruct it :)

But given the TM code is on life support we could probably drop
tm_scratch.

I don't think we've used it in anger for several years. Probably since
265e60a170d0 ("powerpc/64s: Use emergency stack for kernel TM Bad Thing
program checks") (Oct 2017).

If one of us has to debug some hairy TM issue we can always add it back
temporarily in a dev kernel.

cheers


More information about the Linuxppc-dev mailing list