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
next prev parent 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 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).