linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Ingo Molnar <mingo@redhat.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>,
	Steven Rostedt <rostedt@goodmis.org>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 13/22] powerpc/ftrace: Use PPC_RAW_xxx() macros instead of opencoding.
Date: Thu, 5 May 2022 18:47:56 +0200	[thread overview]
Message-ID: <c10a1d91-bf3e-a0d9-dd2b-05174eae6750@csgroup.eu> (raw)
In-Reply-To: <4d338e24-7801-d17c-04a4-9afd2d7f9fd8@csgroup.eu>



Le 04/05/2022 à 14:39, Christophe Leroy a écrit :
> 
> 
> Le 18/04/2022 à 09:38, Naveen N. Rao a écrit :
>> Christophe Leroy wrote:
>>> PPC_RAW_xxx() macros are self explanatory and less error prone
>>> than open coding.
>>>
>>> Use them in ftrace.c
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> ---
>>>   arch/powerpc/include/asm/ppc-opcode.h |  3 +++
>>>   arch/powerpc/kernel/trace/ftrace.c    | 32 +++++++++------------------
>>>   2 files changed, 14 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/ppc-opcode.h
>>> b/arch/powerpc/include/asm/ppc-opcode.h
>>> index 82f1f0041c6f..281754aca0a3 100644
>>> --- a/arch/powerpc/include/asm/ppc-opcode.h
>>> +++ b/arch/powerpc/include/asm/ppc-opcode.h
>>> @@ -294,6 +294,8 @@
>>>   #define PPC_INST_BL            0x48000001
>>>   #define PPC_INST_BRANCH_COND        0x40800000
>>>
>>> +#define PPC_INST_OFFSET24_MASK        0x03fffffc
>>
>> This corresponds to the LI field, per the ISA. See section 8.1.2/1.7:
>> 'Instruction Fields'. Would it be better to name it PPC_INST_LI_MASK?
> 
> Isn't there a risk of confusing with the 'li' instruction ? Like we
> could have PPC_INST_LI just like we have PPC_INST_ADD ?

I called it PPC_LI() and PPC_LI_MASK, similar to PPC_LO, PPC_HI etc ...

> 
> 
> 
>>
>>> +
>>>   /* Prefixes */
>>>   #define PPC_INST_LFS            0xc0000000
>>>   #define PPC_INST_STFS            0xd0000000
>>> @@ -572,6 +574,7 @@
>>>   #define PPC_RAW_EIEIO()            (0x7c0006ac)
>>>
>>>   #define PPC_RAW_BRANCH(addr)        (PPC_INST_BRANCH | ((addr) &
>>> 0x03fffffc))
>>> +#define PPC_RAW_BL(offset)        (0x48000001 | ((offset) &
>>> PPC_INST_OFFSET24_MASK))
>>>
>>>   /* Deal with instructions that older assemblers aren't aware of */
>>>   #define    PPC_BCCTR_FLUSH        stringify_in_c(.long
>>> PPC_INST_BCCTR_FLUSH)
>>> diff --git a/arch/powerpc/kernel/trace/ftrace.c
>>> b/arch/powerpc/kernel/trace/ftrace.c
>>> index fdc0412c1d8a..afb1d12838c9 100644
>>> --- a/arch/powerpc/kernel/trace/ftrace.c
>>> +++ b/arch/powerpc/kernel/trace/ftrace.c
>>> @@ -90,19 +90,19 @@ static int test_24bit_addr(unsigned long ip,
>>> unsigned long addr)
>>>
>>>   static int is_bl_op(ppc_inst_t op)
>>>   {
>>> -    return (ppc_inst_val(op) & 0xfc000003) == 0x48000001;
>>> +    return (ppc_inst_val(op) & ~PPC_INST_OFFSET24_MASK) ==
>>> PPC_RAW_BL(0);
>>>   }
>>>
>>>   static int is_b_op(ppc_inst_t op)
>>>   {
>>> -    return (ppc_inst_val(op) & 0xfc000003) == 0x48000000;
>>> +    return (ppc_inst_val(op) & ~PPC_INST_OFFSET24_MASK) ==
>>> PPC_RAW_BRANCH(0);
>>>   }
>>>
>>>   static unsigned long find_bl_target(unsigned long ip, ppc_inst_t op)
>>>   {
>>>       int offset;
>>>
>>> -    offset = (ppc_inst_val(op) & 0x03fffffc);
>>> +    offset = (ppc_inst_val(op) & PPC_INST_OFFSET24_MASK);
>>>       /* make it signed */
>>>       if (offset & 0x02000000)
>>>           offset |= 0xfe000000;
>>> @@ -182,7 +182,7 @@ __ftrace_make_nop(struct module *mod,
>>>        * Use a b +8 to jump over the load.
>>>        */
>>>
>>> -    pop = ppc_inst(PPC_INST_BRANCH | 8);    /* b +8 */
>>> +    pop = ppc_inst(PPC_RAW_BRANCH(8));    /* b +8 */
>>>
>>>       /*
>>>        * Check what is in the next instruction. We can see ld
>>> r2,40(r1), but
>>> @@ -394,17 +394,8 @@ int ftrace_make_nop(struct module *mod,
>>>   static int
>>>   expected_nop_sequence(void *ip, ppc_inst_t op0, ppc_inst_t op1)
>>>   {
>>> -    /*
>>> -     * We expect to see:
>>> -     *
>>> -     * b +8
>>> -     * ld r2,XX(r1)
>>> -     *
>>> -     * The load offset is different depending on the ABI. For simplicity
>>> -     * just mask it out when doing the compare.
>>> -     */
>>> -    if (!ppc_inst_equal(op0, ppc_inst(0x48000008)) ||
>>> -        (ppc_inst_val(op1) & 0xffff0000) != 0xe8410000)
>>> +    if (!ppc_inst_equal(op0, ppc_inst(PPC_RAW_BRANCH(8))) ||
>>> +        !ppc_inst_equal(op1, ppc_inst(PPC_INST_LD_TOC)))
>>
>> It would be good to move PPC_INST_LD_TOC to ppc-opcode.h
> 
> It's not really just an instruction, it's closely linked to the ABI, so
> does it really belong to ppc-opcode.h ? Maybe it could be better to have
> it in ppc_asm.h instead, which already contains ABI related definitions ?
> 
> If we move it into ppc-opcode.h, then we also have to move
> R2_STACK_OFFSET. Or should we use STK_GOT defined in ppc_asm.h and drop
> R2_STACK_OFFSET ?

Looked at it in more details, looks like STK_GOT is an assembly only 
symbol, and ppc_asm.h is dedicated to ASM allthough it has recently 
leaked a bit into C.

So I propose to leave it as is and do the change in a followup patch.


> 
>>
>>>           return 0;
>>>       return 1;
>>>   }
>>> @@ -412,7 +403,6 @@ expected_nop_sequence(void *ip, ppc_inst_t op0,
>>> ppc_inst_t op1)
>>>   static int
>>>   expected_nop_sequence(void *ip, ppc_inst_t op0, ppc_inst_t op1)
>>>   {
>>> -    /* look for patched "NOP" on ppc64 with -mprofile-kernel or ppc32 */
>>>       if (!ppc_inst_equal(op0, ppc_inst(PPC_RAW_NOP())))
>>>           return 0;
>>>       return 1;
>>> @@ -738,11 +728,11 @@ int __init ftrace_dyn_arch_init(void)
>>>       int i;
>>>       unsigned int *tramp[] = { ftrace_tramp_text, ftrace_tramp_init };
>>>       u32 stub_insns[] = {
>>> -        0xe98d0000 | PACATOC,    /* ld      r12,PACATOC(r13)    */
>>> -        0x3d8c0000,        /* addis   r12,r12,<high>    */
>>> -        0x398c0000,        /* addi    r12,r12,<low>    */
>>> -        0x7d8903a6,        /* mtctr   r12            */
>>> -        0x4e800420,        /* bctr                */
>>> +        PPC_RAW_LD(_R12, _R13, PACATOC),
>>> +        PPC_RAW_ADDIS(_R12, _R12, 0),
>>> +        PPC_RAW_ADDIS(_R12, _R12, 0),
>>
>> This should be PPC_RAW_ADDI.
>>
> 
> Oops.
> 
> Christophe

  reply	other threads:[~2022-05-05 16:48 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-24 14:29 [PATCH v1 00/22] powerpc: ftrace optimisation and cleanup and more [v1] Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 01/22] powerpc/ftrace: Refactor prepare_ftrace_return() Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 02/22] powerpc/ftrace: Remove redundant create_branch() calls Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 03/22] powerpc/code-patching: Inline is_offset_in_{cond}_branch_range() Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 04/22] powerpc/ftrace: Use is_offset_in_branch_range() Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 05/22] powerpc/code-patching: Inline create_branch() Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 06/22] powerpc/ftrace: Inline ftrace_modify_code() Christophe Leroy
2022-04-18  6:07   ` Naveen N. Rao
2022-04-22  9:12     ` Michael Ellerman
2022-05-04 11:43     ` Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 07/22] powerpc/ftrace: Use patch_instruction() return directly Christophe Leroy
2022-04-18  6:21   ` Naveen N. Rao
2022-04-18 19:44     ` Steven Rostedt
2022-05-04 12:01       ` Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 08/22] powerpc/ftrace: Make __ftrace_make_{nop/call}() common to PPC32 and PPC64 Christophe Leroy
2022-04-18  6:40   ` Naveen N. Rao
2022-05-04 12:19     ` Christophe Leroy
2022-05-06 11:41     ` Christophe Leroy
2022-03-24 14:29 ` [PATCH v1 09/22] powerpc/ftrace: Don't include ftrace.o for CONFIG_FTRACE_SYSCALLS Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 10/22] powerpc/ftrace: Use CONFIG_FUNCTION_TRACER instead of CONFIG_DYNAMIC_FTRACE Christophe Leroy
2022-04-18  7:00   ` Naveen N. Rao
2022-05-06 11:41     ` Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 11/22] powerpc/ftrace: Remove ftrace_plt_tramps[] Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 12/22] powerpc/ftrace: Use BRANCH_SET_LINK instead of value 1 Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 13/22] powerpc/ftrace: Use PPC_RAW_xxx() macros instead of opencoding Christophe Leroy
2022-04-18  7:38   ` Naveen N. Rao
2022-05-04 12:39     ` Christophe Leroy
2022-05-05 16:47       ` Christophe Leroy [this message]
2022-03-24 14:30 ` [PATCH v1 14/22] powerpc/ftrace: Use size macro " Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 15/22] powerpc/ftrace: Simplify expected_nop_sequence() Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 16/22] powerpc/ftrace: Minimise number of #ifdefs Christophe Leroy
2022-04-18  7:59   ` Naveen N. Rao
2022-05-04 12:44     ` Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 17/22] powerpc/inst: Add __copy_inst_from_kernel_nofault() Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 18/22] powerpc/ftrace: Don't use copy_from_kernel_nofault() in module_trampoline_target() Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 19/22] powerpc/inst: Remove PPC_INST_BRANCH Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 20/22] powerpc/modules: Use PPC_INST_BRANCH_MASK instead of opencoding Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 21/22] powerpc/inst: Remove PPC_INST_BL Christophe Leroy
2022-03-24 14:30 ` [PATCH v1 22/22] powerpc/opcodes: Remove unused PPC_INST_XXX macros Christophe Leroy

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=c10a1d91-bf3e-a0d9-dd2b-05174eae6750@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=rostedt@goodmis.org \
    /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).