[00/14] arm64: eBPF JIT compiler

Message ID 1405708100-13604-1-git-send-email-zlim.lnx@gmail.com
State New
Headers show

Pull-request

https://github.com/zlim/linux.git arm64/bpf

Message

Zi Shen Lim July 18, 2014, 6:28 p.m.
This series implements eBPF JIT compiler for arm64.
Please see [14/14] for change log.

Patches [1-13/14] implement code generation functions.
Patch [14/14] implements the actual eBPF JIT compiler.

Many thanks to everyone who's reviewed the code from
RFCv1->RFCv3, especially Alexei for BPF bits, and Will
for ARM64 codegen bits :)

BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits).
Should I add a patch updating MAINTAINERS as Patch 15?

This series requires a patch that exports a function
from net/core (resulting from RFCv1 discussion). This patch
has been merged into net-next @ 9f12fbe603f7
("net: filter: move load_pointer() into filter.h").

This series applies against net-next and is tested working
with lib/test_bpf on ARMv8 Foundation Model.

-----
The following changes since commit da388973d4a15e71cada1219d625b5393c90e5ae:

  iw_cxgb4: fix for 64-bit integer division (2014-07-17 16:52:08 -0700)

are available in the git repository at:

  https://github.com/zlim/linux.git arm64/bpf

for you to fetch changes up to eef34dcb8bb9a3712091e0cdea4a1c3a6e42912a:

  arm64: eBPF JIT compiler (2014-07-18 11:06:28 -0700)

----------------------------------------------------------------
Zi Shen Lim (14):
  arm64: introduce aarch64_insn_gen_comp_branch_imm()
  arm64: introduce aarch64_insn_gen_branch_reg()
  arm64: introduce aarch64_insn_gen_cond_branch_imm()
  arm64: introduce aarch64_insn_gen_load_store_reg()
  arm64: introduce aarch64_insn_gen_load_store_pair()
  arm64: introduce aarch64_insn_gen_add_sub_imm()
  arm64: introduce aarch64_insn_gen_bitfield()
  arm64: introduce aarch64_insn_gen_movewide()
  arm64: introduce aarch64_insn_gen_add_sub_shifted_reg()
  arm64: introduce aarch64_insn_gen_data1()
  arm64: introduce aarch64_insn_gen_data2()
  arm64: introduce aarch64_insn_gen_data3()
  arm64: introduce aarch64_insn_gen_logical_shifted_reg()
  arm64: eBPF JIT compiler

 Documentation/networking/filter.txt |   2 +-
 arch/arm64/Kconfig                  |   1 +
 arch/arm64/Makefile                 |   1 +
 arch/arm64/include/asm/insn.h       | 249 +++++++++++++
 arch/arm64/kernel/insn.c            | 646 +++++++++++++++++++++++++++++++++-
 arch/arm64/net/Makefile             |   4 +
 arch/arm64/net/bpf_jit.h            | 169 +++++++++
 arch/arm64/net/bpf_jit_comp.c       | 677 ++++++++++++++++++++++++++++++++++++
 8 files changed, 1741 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/net/Makefile
 create mode 100644 arch/arm64/net/bpf_jit.h
 create mode 100644 arch/arm64/net/bpf_jit_comp.c

Comments

Will Deacon July 21, 2014, 9:16 a.m. | #1
Hello,

On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
> This series implements eBPF JIT compiler for arm64.
> Please see [14/14] for change log.
> 
> Patches [1-13/14] implement code generation functions.
> Patch [14/14] implements the actual eBPF JIT compiler.
> 
> Many thanks to everyone who's reviewed the code from
> RFCv1->RFCv3, especially Alexei for BPF bits, and Will
> for ARM64 codegen bits :)
> 
> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits).
> Should I add a patch updating MAINTAINERS as Patch 15?

I don't think that's necessary at the moment, but if we start seeing an
influx of patches to arch/arm64/net, then that could make sense in the
future.

> This series requires a patch that exports a function
> from net/core (resulting from RFCv1 discussion). This patch
> has been merged into net-next @ 9f12fbe603f7
> ("net: filter: move load_pointer() into filter.h").
> 
> This series applies against net-next and is tested working
> with lib/test_bpf on ARMv8 Foundation Model.

Looks like it works on my Juno board too, so:

  Acked-by: Will Deacon <will.deacon@arm.com>

for the series.

It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
also means the dependency on -next isn't an issue). Perhaps you could repost
around -rc3?

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alexei Starovoitov July 21, 2014, 3:49 p.m. | #2
On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
> Hello,
>
> On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
>> This series implements eBPF JIT compiler for arm64.
>> Please see [14/14] for change log.
>>
>> Patches [1-13/14] implement code generation functions.
>> Patch [14/14] implements the actual eBPF JIT compiler.
>>
>> Many thanks to everyone who's reviewed the code from
>> RFCv1->RFCv3, especially Alexei for BPF bits, and Will
>> for ARM64 codegen bits :)
>>
>> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits).
>> Should I add a patch updating MAINTAINERS as Patch 15?
>
> I don't think that's necessary at the moment, but if we start seeing an
> influx of patches to arch/arm64/net, then that could make sense in the
> future.
>
>> This series requires a patch that exports a function
>> from net/core (resulting from RFCv1 discussion). This patch
>> has been merged into net-next @ 9f12fbe603f7
>> ("net: filter: move load_pointer() into filter.h").
>>
>> This series applies against net-next and is tested working
>> with lib/test_bpf on ARMv8 Foundation Model.
>
> Looks like it works on my Juno board too, so:
>
>   Acked-by: Will Deacon <will.deacon@arm.com>
>
> for the series.
>
> It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
> also means the dependency on -next isn't an issue). Perhaps you could repost
> around -rc3?

Thanks for testing! Nice to see it working on real hw.
I'm not sure why you're proposing a 4+ week delay. The patches
will rot instead of getting used and tested. Imo it makes sense to
get them into net-next now for 3.17.
JIT is disabled by sysctl by default anyway.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Catalin Marinas July 23, 2014, 10:32 a.m. | #3
On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
> >> This series implements eBPF JIT compiler for arm64.
> >> Please see [14/14] for change log.
> >>
> >> Patches [1-13/14] implement code generation functions.
> >> Patch [14/14] implements the actual eBPF JIT compiler.
> >>
> >> Many thanks to everyone who's reviewed the code from
> >> RFCv1->RFCv3, especially Alexei for BPF bits, and Will
> >> for ARM64 codegen bits :)
> >>
> >> BTW, I'm happy to maintain arch/arm64/net (i.e. arm64 BPF bits).
> >> Should I add a patch updating MAINTAINERS as Patch 15?
> >
> > I don't think that's necessary at the moment, but if we start seeing an
> > influx of patches to arch/arm64/net, then that could make sense in the
> > future.
> >
> >> This series requires a patch that exports a function
> >> from net/core (resulting from RFCv1 discussion). This patch
> >> has been merged into net-next @ 9f12fbe603f7
> >> ("net: filter: move load_pointer() into filter.h").
> >>
> >> This series applies against net-next and is tested working
> >> with lib/test_bpf on ARMv8 Foundation Model.
> >
> > Looks like it works on my Juno board too, so:
> >
> >   Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > for the series.
> >
> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
> > also means the dependency on -next isn't an issue). Perhaps you could repost
> > around -rc3?
> 
> Thanks for testing! Nice to see it working on real hw.
> I'm not sure why you're proposing a 4+ week delay. The patches
> will rot instead of getting used and tested. Imo it makes sense to
> get them into net-next now for 3.17.
> JIT is disabled by sysctl by default anyway.

We normally like some patches (especially new functionality) to sit in
linux-next for a while before the mering window (ideally starting with
-rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17
merging window.

Another aspect is that the arm64/bpf branch depends on the net tree, so
it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a
problem).
Zi Shen Lim July 24, 2014, 4:55 a.m. | #4
On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
>> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
[...]
>> >> This series applies against net-next and is tested working
>> >> with lib/test_bpf on ARMv8 Foundation Model.
>> >
>> > Looks like it works on my Juno board too, so:
>> >
>> >   Acked-by: Will Deacon <will.deacon@arm.com>
>> >
>> > for the series.
>> >
>> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
>> > also means the dependency on -next isn't an issue). Perhaps you could repost
>> > around -rc3?
>>
>> Thanks for testing! Nice to see it working on real hw.
>> I'm not sure why you're proposing a 4+ week delay. The patches
>> will rot instead of getting used and tested. Imo it makes sense to
>> get them into net-next now for 3.17.
>> JIT is disabled by sysctl by default anyway.
>
> We normally like some patches (especially new functionality) to sit in
> linux-next for a while before the mering window (ideally starting with
> -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17
> merging window.
>
> Another aspect is that the arm64/bpf branch depends on the net tree, so
> it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a
> problem).

Hi Catalin, I take it you prefer this series going through arm64 tree,
targeting 3.18, is that right?

I understand your preference to have it sitting in linux-next for a
longer period for arm64 material, I'll repost this again after 3.17 so
it gets more exposure in linux-next.

BTW, are you open to this series going through net tree? I'm
(preemptively) asking because during development of this series, I've
had to rebase a couple times against net-next to handle dependencies.
Or is the general practice to handle conflicts in linux-next itself?

>
> --
> Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Will Deacon July 24, 2014, 11:32 a.m. | #5
On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote:
> On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
> >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
> [...]
> >> >> This series applies against net-next and is tested working
> >> >> with lib/test_bpf on ARMv8 Foundation Model.
> >> >
> >> > Looks like it works on my Juno board too, so:
> >> >
> >> >   Acked-by: Will Deacon <will.deacon@arm.com>
> >> >
> >> > for the series.
> >> >
> >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
> >> > also means the dependency on -next isn't an issue). Perhaps you could repost
> >> > around -rc3?
> >>
> >> Thanks for testing! Nice to see it working on real hw.
> >> I'm not sure why you're proposing a 4+ week delay. The patches
> >> will rot instead of getting used and tested. Imo it makes sense to
> >> get them into net-next now for 3.17.
> >> JIT is disabled by sysctl by default anyway.
> >
> > We normally like some patches (especially new functionality) to sit in
> > linux-next for a while before the mering window (ideally starting with
> > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17
> > merging window.
> >
> > Another aspect is that the arm64/bpf branch depends on the net tree, so
> > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a
> > problem).
> 
> Hi Catalin, I take it you prefer this series going through arm64 tree,
> targeting 3.18, is that right?

Right.

> I understand your preference to have it sitting in linux-next for a
> longer period for arm64 material, I'll repost this again after 3.17 so
> it gets more exposure in linux-next.

Brill, thanks!

> BTW, are you open to this series going through net tree? I'm
> (preemptively) asking because during development of this series, I've
> had to rebase a couple times against net-next to handle dependencies.
> Or is the general practice to handle conflicts in linux-next itself?

We don't have a problem with it going via the -net tree if there's a reason
for doing so (i.e. a new dependency that crops up after your rebase) but we
should stick with the arm64 tree if we can.

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Will Deacon Aug. 26, 2014, 9:58 a.m. | #6
Hi Z Lim,

On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote:
> On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
> >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
> [...]
> >> >> This series applies against net-next and is tested working
> >> >> with lib/test_bpf on ARMv8 Foundation Model.
> >> >
> >> > Looks like it works on my Juno board too, so:
> >> >
> >> >   Acked-by: Will Deacon <will.deacon@arm.com>
> >> >
> >> > for the series.
> >> >
> >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
> >> > also means the dependency on -next isn't an issue). Perhaps you could repost
> >> > around -rc3?
> >>
> >> Thanks for testing! Nice to see it working on real hw.
> >> I'm not sure why you're proposing a 4+ week delay. The patches
> >> will rot instead of getting used and tested. Imo it makes sense to
> >> get them into net-next now for 3.17.
> >> JIT is disabled by sysctl by default anyway.
> >
> > We normally like some patches (especially new functionality) to sit in
> > linux-next for a while before the mering window (ideally starting with
> > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17
> > merging window.
> >
> > Another aspect is that the arm64/bpf branch depends on the net tree, so
> > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a
> > problem).
> 
> Hi Catalin, I take it you prefer this series going through arm64 tree,
> targeting 3.18, is that right?
> 
> I understand your preference to have it sitting in linux-next for a
> longer period for arm64 material, I'll repost this again after 3.17 so
> it gets more exposure in linux-next.

Any chance you could post a new version of this, based on a 3.17 -rc,
please? Whilst your current patches apply, I get a bunch of errors if I try
to build them.

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Zi Shen Lim Aug. 27, 2014, 2:02 a.m. | #7
Hi Will,

On Tue, Aug 26, 2014 at 2:58 AM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Z Lim,
>
> On Thu, Jul 24, 2014 at 05:55:36AM +0100, Z Lim wrote:
>> On Wed, Jul 23, 2014 at 3:32 AM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>> > On Mon, Jul 21, 2014 at 04:49:29PM +0100, Alexei Starovoitov wrote:
>> >> On Mon, Jul 21, 2014 at 2:16 AM, Will Deacon <will.deacon@arm.com> wrote:
>> >> > On Fri, Jul 18, 2014 at 07:28:06PM +0100, Zi Shen Lim wrote:
>> [...]
>> >> >> This series applies against net-next and is tested working
>> >> >> with lib/test_bpf on ARMv8 Foundation Model.
>> >> >
>> >> > Looks like it works on my Juno board too, so:
>> >> >
>> >> >   Acked-by: Will Deacon <will.deacon@arm.com>
>> >> >
>> >> > for the series.
>> >> >
>> >> > It's a bit late for 3.17 now, so I guess we'll queue this for 3.18 (which
>> >> > also means the dependency on -next isn't an issue). Perhaps you could repost
>> >> > around -rc3?
>> >>
>> >> Thanks for testing! Nice to see it working on real hw.
>> >> I'm not sure why you're proposing a 4+ week delay. The patches
>> >> will rot instead of getting used and tested. Imo it makes sense to
>> >> get them into net-next now for 3.17.
>> >> JIT is disabled by sysctl by default anyway.
>> >
>> > We normally like some patches (especially new functionality) to sit in
>> > linux-next for a while before the mering window (ideally starting with
>> > -rc4 or -rc5). We are at -rc6 already, so getting close to the 3.17
>> > merging window.
>> >
>> > Another aspect is that the arm64/bpf branch depends on the net tree, so
>> > it can't easily go in via the arm64 tree for 3.17 (3.18 would not be a
>> > problem).
>>
>> Hi Catalin, I take it you prefer this series going through arm64 tree,
>> targeting 3.18, is that right?
>>
>> I understand your preference to have it sitting in linux-next for a
>> longer period for arm64 material, I'll repost this again after 3.17 so
>> it gets more exposure in linux-next.
>
> Any chance you could post a new version of this, based on a 3.17 -rc,
> please? Whilst your current patches apply, I get a bunch of errors if I try
> to build them.

Sure. I just rebased onto -rc2 and fixed up as necessary due to
changes introduced in net.
I'll post a v2 shortly.

Thanks for the reminder :)

z

>
> Cheers,
>
> Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/