[PATCH 0/2] powerpc: Disable syscall emulation and stepping

[Nicholas Piggin]

Excerpts from naverao1's message of January 25, 2022 8:48 pm:
> On 2022-01-25 11:23, Christophe Leroy wrote:
>> Le 25/01/2022 à 04:04, Nicholas Piggin a écrit :
>>> +Naveen (sorry missed cc'ing you at first)
>>> 
>>> Excerpts from Christophe Leroy's message of January 24, 2022 4:39 pm:
>>>> 
>>>> 
>>>> Le 24/01/2022 à 06:57, Nicholas Piggin a écrit :
>>>>> As discussed previously
>>>>> 
>>>>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-January/238946.html
>>>>> 
>>>>> I'm wondering whether PPC32 should be returning -1 for syscall
>>>>> instructions too here? That could be done in another patch anyway.
>>>>> 
>>>> 
>>>> The 'Programming Environments Manual for 32-Bit Implementations of 
>>>> the
>>>> PowerPC™ Architecture' says:
>>>> 
>>>> The following are not traced:
>>>> • rfi instruction
>>>> • sc and trap instructions that trap
>>>> • Other instructions that cause interrupts (other than trace 
>>>> interrupts)
>>>> • The first instruction of any interrupt handler
>>>> • Instructions that are emulated by software
>>>> 
>>>> 
>>>> So I think PPC32 should return -1 as well.
>>> 
>>> I agree.
>>> 
>>> What about the trap instructions? analyse_instr returns 0 for them
>>> which falls through to return 0 for emulate_step, should they
>>> return -1 as well or am I missing something?
> 
> Yeah, good point about the trap instructions.
> 
>>> 
>> 
>> For the traps I don't know. The manual says "trap instructions that
>> trap" are not traced. It means that "trap instructions that _don't_
>> trap" are traced. Taking into account that trap instructions don't trap
>> at least 99.9% of the time, not sure if returning -1 is needed.
>> 
>> Allthought that'd probably be the safest.
> 
> 'trap' is a special case since it is predominantly used by debuggers
> and/or tracing infrastructure. Kprobes and Uprobes do not allow probes
> on a trap instruction. But, xmon can be asked to step on a trap
> instruction and that can interfere with kprobes in weird ways.
> 
> So, I think it is best if we also exclude trap instructions from being
> single stepped.
> 
>> 
>> But then what happens with other instruction that will sparsely 
>> generate
>> an exception like a DSI or so ? If we do it for the traps then we 
>> should
>> do it for this as well, and then it becomes a non ending story.
> 
> For a DSI, we restart the same instruction after handling the page 
> fault.
> The single step exception is raised on the subsequent successful
> completion of the instruction.

Although it can cause a signal, and the signal handler can decide
to resume somewhere else. Or kernel mode equivalent it can go to a
fixup handler and resume somewhere else.

How are those handled?

Thanks,
Nick

> For most other interrupts (alignment, vsx
> unavailable, ...), we end up emulating the single step exception itself
> (see emulate_single_step()). So, those are ok if caused by an 
> instruction
> being stepped.
> 
> 
> - Naveen
>