All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Balamuruhan S <bala24@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>
Cc: jniethe5@gmail.com, linuxppc-dev@lists.ozlabs.org,
	sandipan@linux.ibm.com, paulus@samba.org,
	ravi.bangoria@linux.ibm.com
Subject: Re: [RFC PATCH 3/4] powerpc ppc-opcode: move ppc instuction encoding from test_emulate_step
Date: Thu, 02 Apr 2020 12:34:32 +0530	[thread overview]
Message-ID: <1585810752.gtbei2f2gy.naveen@linux.ibm.com> (raw)
In-Reply-To: <87ftdmtsy9.fsf@mpe.ellerman.id.au>

Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
>> Balamuruhan S wrote:
>>> Few ppc instructions are encoded in test_emulate_step.c, consolidate them to
>>> ppc-opcode.h, fix redefintion errors in bpf_jit caused due to this consolidation.
>>> Reuse the macros from ppc-opcode.h
> ...
>>> diff --git a/arch/powerpc/net/bpf_jit32.h b/arch/powerpc/net/bpf_jit32.h
>>> index 4ec2a9f14f84..8a9f16a7262e 100644
>>> --- a/arch/powerpc/net/bpf_jit32.h
>>> +++ b/arch/powerpc/net/bpf_jit32.h
>>> @@ -76,13 +76,13 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
>>>  		else {	PPC_ADDIS(r, base, IMM_HA(i));			      \
>>>  			PPC_LBZ(r, r, IMM_L(i)); } } while(0)
>>> 
>>> -#define PPC_LD_OFFS(r, base, i) do { if ((i) < 32768) PPC_LD(r, base, i);     \
>>> +#define _OFFS(r, base, i) do { if ((i) < 32768) EMIT(PPC_ENCODE_LD(r, base, i));     \
>> 	   ^^^^^
>> Should be PPC_LD_OFFS. For the next version, please also build ppc32 and 
>> booke codebase to confirm that your changes in those areas are fine.
>>
>> PPC_ENCODE_* also looks quite verbose, so perhaps PPC_ENC_* might be 
>> better. Otherwise, this patchset looks good to me and should help reuse 
>> some of those macros, especially from the eBPF codebase.
>>
>> Michael,
>> Can you let us know if this looks ok to you? Based on your feedback, we 
>> will also update the eBPF codebase.
> 
> I didn't really like the first patch which does the mass renaming. It
> creates a huge amount of churn.
> 
> I think I'd be happier if this series just did what it needs, and then
> maybe at the end there's a patch to update all the existing names, which
> I may or may not take.

Ok.

> 
> As far as the naming, currently we have:
> 
> PPC_INST_FOO - just the opcode
> 
> PPC_FOO(x) - macro to encode the opcode with x and (usually) also emit a
>             .long and stringify.
> 
> And you need an in-between that gives you the full instruction but
> without the .long and stringify, right?

Yes.

> 
> So how about PPC_RAW_FOO() for just the numeric value, without the .long
> and stringify.

Sure, thanks for the feedback -- that makes sense.

> 
> We also seem to have a lot of PPC_INST_FOO's that are only ever used in
> the PPC_INST macro. I'm inclined to fold those into the PPC_INST macro,
> to avoid people accidentally using the PPC_INST version when they don't
> mean to. But that's a separate issue.

Good point -- I do see many uses of PPC_INST_FOO that can be replaced 
with PPC_RAW_FOO once we introduce that. We will take a stab at doing 
this cleanup as a separate patch at the end.


Thanks,
Naveen


  reply	other threads:[~2020-04-02  7:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-20  8:18 [RFC PATCH 0/4] consolidate PowerPC instruction encoding macros Balamuruhan S
2020-03-20  8:18 ` [RFC PATCH 1/4] powerpc ppc-opcode: introduce PPC_ENCODE_* macros for base instruction encoding Balamuruhan S
2020-03-20  8:18 ` [RFC PATCH 2/4] powerpc selftest: reuse ppc-opcode macros to avoid redundancy Balamuruhan S
2020-03-20  8:18 ` [RFC PATCH 3/4] powerpc ppc-opcode: move ppc instuction encoding from test_emulate_step Balamuruhan S
2020-04-01 16:51   ` Naveen N. Rao
2020-04-02  4:25     ` Michael Ellerman
2020-04-02  7:04       ` Naveen N. Rao [this message]
2020-04-03  7:14         ` Balamuruhan S
2020-03-20  8:18 ` [RFC PATCH 4/4] powerpc kvm_asm: rename PPC_LD and PPC_STD macros to avoid redefinition Balamuruhan S

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=1585810752.gtbei2f2gy.naveen@linux.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=bala24@linux.ibm.com \
    --cc=jniethe5@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=ravi.bangoria@linux.ibm.com \
    --cc=sandipan@linux.ibm.com \
    /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.