Re: [PATCH] RFC: arm: eBPF JIT compiler
On Thu, May 25, 2017 at 12:44:19PM -0700, Florian Fainelli wrote: > Using QEMU is far less complex than the patch you wrote, the tricky > point me be to find an ARMv6 root filesystem, unless you build the > module into the kernel and let it run its tests. I beg to differ - when I tried qemu during the last year, it was basically completely non-functional for ARM, and I gave up with it. I think what you get depends on your distro. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH] RFC: arm: eBPF JIT compiler
On 05/25/2017 01:08 PM, Shubham Bansal wrote: > Hi Florian, > > It would be great if you could help me with it. > > Currently, what I am doing is. > > root@arm$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make -j4 > > Then I am using Busybox to build the root filesystem > > root@arm$ qemu-system-arm -M vexpress-a9 -dtb > ./linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -kernel > ./linux/arch/arm/boot/zImage -append "root=/dev/mmcblk0 > console=ttyAMA0" -sd ./a9rootfs.ext3 --nographic > > Which machine I should use for ARMv6 in QEMU. Which dtb file I should > use for ? All these questions I have. If anybody knows please let me > know. You should use realview-eb-mpcore for instance (ARM11MPCORE is ARMv6). > > > Best, > Shubham Bansal > > > On Fri, May 26, 2017 at 1:14 AM, Florian Fainelli > wrote: >> On 05/25/2017 12:09 PM, Shubham Bansal wrote: >>> Hi Andrew, >>> >>> On Fri, May 26, 2017 at 12:18 AM, Andrew Lunn wrote: On Fri, May 26, 2017 at 12:05:23AM +0530, Shubham Bansal wrote: > Hi Andrew, > > My Apologies. > > I will remove the #ifdef CONFIG_CPU_LITTLE_ENDIAN. Do you have the > ARMv6 machine you can test it on? Sorry, i don't have a v6. Maybe try kzm with qemu-system-qemu? >>> >>> I am afraid I not so familiar with qemu, otherwise I would have tried >>> to test the code on ARMv5,6,7 myself. >>> If you can help me with that it would be great, Otherwise I think I >>> have to wait for someone to test it for ARMv6. Although, I am pretty >>> sure it would work on that as it worked on ARMv5. >> >> Using QEMU is far less complex than the patch you wrote, the tricky >> point me be to find an ARMv6 root filesystem, unless you build the >> module into the kernel and let it run its tests. >> -- >> Florian -- Florian
Re: [PATCH] RFC: arm: eBPF JIT compiler
For what it's worth, I did an comparison of the numbers Shubham posted in another thread for the JIT, comparing the eBPF interpreter with his new JIT. The post is here: https://www.spinics.net/lists/netdev/msg436402.html -Kees -- Kees Cook Pixel Security
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Florian, It would be great if you could help me with it. Currently, what I am doing is. root@arm$ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make -j4 Then I am using Busybox to build the root filesystem root@arm$ qemu-system-arm -M vexpress-a9 -dtb ./linux/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -kernel ./linux/arch/arm/boot/zImage -append "root=/dev/mmcblk0 console=ttyAMA0" -sd ./a9rootfs.ext3 --nographic Which machine I should use for ARMv6 in QEMU. Which dtb file I should use for ? All these questions I have. If anybody knows please let me know. Best, Shubham Bansal On Fri, May 26, 2017 at 1:14 AM, Florian Fainelli wrote: > On 05/25/2017 12:09 PM, Shubham Bansal wrote: >> Hi Andrew, >> >> On Fri, May 26, 2017 at 12:18 AM, Andrew Lunn wrote: >>> On Fri, May 26, 2017 at 12:05:23AM +0530, Shubham Bansal wrote: Hi Andrew, My Apologies. I will remove the #ifdef CONFIG_CPU_LITTLE_ENDIAN. Do you have the ARMv6 machine you can test it on? >>> >>> Sorry, i don't have a v6. >>> >>> Maybe try kzm with qemu-system-qemu? >> >> I am afraid I not so familiar with qemu, otherwise I would have tried >> to test the code on ARMv5,6,7 myself. >> If you can help me with that it would be great, Otherwise I think I >> have to wait for someone to test it for ARMv6. Although, I am pretty >> sure it would work on that as it worked on ARMv5. > > Using QEMU is far less complex than the patch you wrote, the tricky > point me be to find an ARMv6 root filesystem, unless you build the > module into the kernel and let it run its tests. > -- > Florian
Re: [PATCH] RFC: arm: eBPF JIT compiler
On 05/25/2017 12:09 PM, Shubham Bansal wrote: > Hi Andrew, > > On Fri, May 26, 2017 at 12:18 AM, Andrew Lunn wrote: >> On Fri, May 26, 2017 at 12:05:23AM +0530, Shubham Bansal wrote: >>> Hi Andrew, >>> >>> My Apologies. >>> >>> I will remove the #ifdef CONFIG_CPU_LITTLE_ENDIAN. Do you have the >>> ARMv6 machine you can test it on? >> >> Sorry, i don't have a v6. >> >> Maybe try kzm with qemu-system-qemu? > > I am afraid I not so familiar with qemu, otherwise I would have tried > to test the code on ARMv5,6,7 myself. > If you can help me with that it would be great, Otherwise I think I > have to wait for someone to test it for ARMv6. Although, I am pretty > sure it would work on that as it worked on ARMv5. Using QEMU is far less complex than the patch you wrote, the tricky point me be to find an ARMv6 root filesystem, unless you build the module into the kernel and let it run its tests. -- Florian
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Andrew, On Fri, May 26, 2017 at 12:18 AM, Andrew Lunn wrote: > On Fri, May 26, 2017 at 12:05:23AM +0530, Shubham Bansal wrote: >> Hi Andrew, >> >> My Apologies. >> >> I will remove the #ifdef CONFIG_CPU_LITTLE_ENDIAN. Do you have the >> ARMv6 machine you can test it on? > > Sorry, i don't have a v6. > > Maybe try kzm with qemu-system-qemu? I am afraid I not so familiar with qemu, otherwise I would have tried to test the code on ARMv5,6,7 myself. If you can help me with that it would be great, Otherwise I think I have to wait for someone to test it for ARMv6. Although, I am pretty sure it would work on that as it worked on ARMv5. > > Andrew -Shubham
Re: [PATCH] RFC: arm: eBPF JIT compiler
On Fri, May 26, 2017 at 12:05:23AM +0530, Shubham Bansal wrote: > Hi Andrew, > > My Apologies. > > I will remove the #ifdef CONFIG_CPU_LITTLE_ENDIAN. Do you have the > ARMv6 machine you can test it on? Sorry, i don't have a v6. Maybe try kzm with qemu-system-qemu? Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Andrew, My Apologies. I will remove the #ifdef CONFIG_CPU_LITTLE_ENDIAN. Do you have the ARMv6 machine you can test it on? -Shubham
Re: [PATCH] RFC: arm: eBPF JIT compiler
On Thu, May 25, 2017 at 11:30:36PM +0530, Shubham Bansal wrote: > Actually I intentionally put that print statement their. Hi Shubham Please don't top post. > Can you tell me what ifdef you removed ? #ifdef CONFIG_CPU_LITTLE_ENDIAN Since i said, ARM does not seem to use it. Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
On Thu, May 25, 2017 at 07:00:51PM +0200, Andrew Lunn wrote: > On Thu, May 25, 2017 at 02:01:36AM +0530, Shubham Bansal wrote: > > Hi Andrew, > > > > I am attaching the latest patch which should work on ARMv5 , ARMv6 and > > ARMv7. > > > > Please test on your machines. Apologies for the last patch. This patch > > should work though. > > andrew@shuttle:~/linux$ make -s -j 16 > arch/arm/net/bpf_jit_32.c:1755:12: warning: âvalidate_codeâ defined but > not used [-Wunused-function] > static int validate_code(struct jit_ctx *ctx) > ^ > arch/arm/net/bpf_jit_32.c:1724:12: warning: âbuild_bodyâ defined but not > used [-Wunused-function] > static int build_body(struct jit_ctx *ctx) > ^~ > arch/arm/net/bpf_jit_32.c:1122:13: warning: âbuild_epilogueâ defined but > not used [-Wunused-function] > static void build_epilogue(struct jit_ctx *ctx) > ^~ > arch/arm/net/bpf_jit_32.c:1049:13: warning: âbuild_prologueâ defined but > not used [-Wunused-function] > static void build_prologue(struct jit_ctx *ctx) > ^~ > arch/arm/net/bpf_jit_32.c:174:13: warning: âjit_fill_holeâ defined but > not used [-Wunused-function] > static void jit_fill_hole(void *area, unsigned int size) > ^ > > I _think_ this is because CONFIG_CPU_LITTLE_ENDIAN is not set. But it > is a little endian machine/configuration. ARM does not seem to use > CONFIG_CPU_LITTLE_ENDIAN, it just has CPU_BIG_ENDIAN. After removing the #ifdef: test_bpf: Summary: 314 PASSED, 0 FAILED, [272/306 JIT'ed] Each test prints: ARM version : 5 ARM version : 5 So the code needs some cleanup, but seems to basically work. Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
On Thu, May 25, 2017 at 02:01:36AM +0530, Shubham Bansal wrote: > Hi Andrew, > > I am attaching the latest patch which should work on ARMv5 , ARMv6 and ARMv7. > > Please test on your machines. Apologies for the last patch. This patch > should work though. andrew@shuttle:~/linux$ make -s -j 16 arch/arm/net/bpf_jit_32.c:1755:12: warning: âvalidate_codeâ defined but not used [-Wunused-function] static int validate_code(struct jit_ctx *ctx) ^ arch/arm/net/bpf_jit_32.c:1724:12: warning: âbuild_bodyâ defined but not used [-Wunused-function] static int build_body(struct jit_ctx *ctx) ^~ arch/arm/net/bpf_jit_32.c:1122:13: warning: âbuild_epilogueâ defined but not used [-Wunused-function] static void build_epilogue(struct jit_ctx *ctx) ^~ arch/arm/net/bpf_jit_32.c:1049:13: warning: âbuild_prologueâ defined but not used [-Wunused-function] static void build_prologue(struct jit_ctx *ctx) ^~ arch/arm/net/bpf_jit_32.c:174:13: warning: âjit_fill_holeâ defined but not used [-Wunused-function] static void jit_fill_hole(void *area, unsigned int size) ^ I _think_ this is because CONFIG_CPU_LITTLE_ENDIAN is not set. But it is a little endian machine/configuration. ARM does not seem to use CONFIG_CPU_LITTLE_ENDIAN, it just has CPU_BIG_ENDIAN. Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Andrew, Did you get the chance to test the patch? Best, Shubham Bansal On Thu, May 25, 2017 at 2:01 AM, Shubham Bansal wrote: > Hi Andrew, > > I am attaching the latest patch which should work on ARMv5 , ARMv6 and ARMv7. > > Please test on your machines. Apologies for the last patch. This patch > should work though. > > Best, > Shubham Bansal > > > On Wed, May 24, 2017 at 4:55 AM, Andrew Lunn wrote: >> root@qnap:~# test_bpf: #0 TAX jited:0 241 466 241 PASS >> test_bpf: #1 TXA jited:1 51 117 51 PASS >> test_bpf: #2 ADD_SUB_MUL_K jited:0 167 PASS >> test_bpf: #3 DIV_MOD_KX jited:0 571 PASS >> test_bpf: #4 AND_OR_LSH_K jited:1 54 54 PASS >> test_bpf: #5 LD_IMM_0 jited:1 45 PASS >> test_bpf: #6 LD_IND jited:0 143 143 143 PASS >> test_bpf: #7 LD_ABS jited:0 120 133 120 PASS >> test_bpf: #8 LD_ABS_LL >> Unable to handle kernel paging request at virtual address 9e096420 >> pgd = daa3 >> [9e096420] *pgd= >> Internal error: Oops: 805 [#1] PREEMPT ARM >> Modules linked in: test_bpf(+) [last unloaded: test_bpf] >> CPU: 0 PID: 1886 Comm: modprobe Not tainted >> 4.12.0-rc2-00275-g17a0ff4ded06-dirty #1784 >> Hardware name: Marvell Kirkwood (Flattened Device Tree) >> task: df7d4ba0 task.stack: de738000 >> PC is at imm_offset+0xa4/0x108 >> LR is at 0x8 >> pc : []lr : [<0008>]psr: 6013 >> sp : de739c6c ip : 002c fp : 0003 >> r10: de739cf8 r9 : e1356000 r8 : 001c >> r7 : de59c840 r6 : de59c840 r5 : bf2c2944 r4 : >> r3 : dedd3adc r2 : dedd3adc r1 : de739cf8 r0 : ffe0 >> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none >> Control: 0005397f Table: 1aa3 DAC: 0051 >> Process modprobe (pid: 1886, stack limit = 0xde738190) >> Stack: (0xde739c6c to 0xde73a000) >> 9c60:0001 0030 0003 c05c5d5e c001a560 >> 9c80: de739cf4 e1356038 c05c5d34 ffe0 c05c5d42 >> 9ca0: 001a e1356000 5e3b2a64 0f04 e1356000 >> 9cc0: e1356000 c078105c 00f8 bf2c2000 bf1661c0 c001c64c >> 9ce0: de57f0c8 0008 0002 de739d54 0eec bf2c2944 e1356000 001c >> 9d00: 002c 0038 0001 de59c9a0 bf2c2944 00040008 de59c840 >> 9d20: e1356000 de739d50 de57f0c0 0005 de59c9a0 0001 c008fb98 >> 9d40: e1356000 e1356000 de57f0c0 c04a8384 0008 e1356000 de739dd8 >> 9d60: e1356000 0028 de739dd4 bf165140 bf1661c0 c04a84d0 >> 9d80: 0005 e1354000 bf1651c8 e1354000 bf2af218 dedcfd20 e000 >> 9da0: df45ef80 bf1651c4 0008 0008 0003 0008 0003 >> 9dc0: bf1650a5 bf165144 79f5179d 004e e1354000 0005 bf1651c8 >> 9de0: e000 bf2af000 de57f9e4 0001 bf2acee0 c007aa88 >> 9e00: 0124 c0009738 0001 dfbe78b0 c07c25ac 0080007f >> 9e20: dfbe78a4 001f dffc3d60 de738000 df401f00 >> 9e40: de56b080 c007d6e0 00016acf c007aa88 bf2acee0 0001 de59c280 0001 >> 9e60: bf2acee0 c00a1548 0001 de57f9c0 de739f54 0001 de57f9c0 c007d6e8 >> 9e80: bf2aceec 7fff bf2acee0 c007afd4 de739f48 bf2acf28 >> 9ea0: bf2ad074 e1344928 c05c76a8 bf2aceec de739f44 c00f6fa8 >> 9ec0: 001879a0 c00f7684 >> 9ee0: >> 9f00: 7fff 0003 7f59f510 017b c000a544 >> 9f20: de738000 c007de58 7fff 0003 >> 9f40: e11bd000 001879a0 0874 e11bd000 001879a0 e13441d0 >> 9f60: e1343ff0 e1337960 00154550 001547c0 14ec >> 9f80: 002f 0030 001b 0015 ca81c300 7f5b2810 >> 9fa0: c000a3a0 ca81c300 7f5b2810 0003 7f59f510 7f59fd00 >> 9fc0: ca81c300 7f5b2810 017b 7f59f510 7f5b21d0 >> 9fe0: bee273a0 bee27390 7f593acc b6ed1130 6010 0003 >> [] (imm_offset) from [] (build_body+0x5164/0x70ec) >> [] (build_body) from [] (bpf_int_jit_compile+0x160/0x314) >> [] (bpf_int_jit_compile) from [] >> (bpf_prog_select_runtime+0x14/0x124) >> [] (bpf_prog_select_runtime) from [] >> (bpf_prepare_filter+0x7b0/0x888) >> [] (bpf_prepare_filter) from [] >> (bpf_prog_create+0x74/0xa4) >> [] (bpf_prog_create) from [] (test_bpf_init+0x218/0x77c >> [test_bpf]) >> [] (test_bpf_init [test_bpf]) from [] >> (do_one_initcall+0x40/0x178) >> [] (do_one_initcall) from [] (do_init_module+0x58/0x1bc) >> [] (do_init_module) from [] (load_module+0x1ae0/0x2050) >> [] (load_module) from [] (SyS_finit_module+0xa4/0xb8) >> [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x38) >> >> Looking at the .lst file: >> >> /* constants go just after the epilogue */ >> offset = ctx->offsets[ctx->prog->len]; >> c0015054: e591c00
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Andrew, I am attaching the latest patch which should work on ARMv5 , ARMv6 and ARMv7. Please test on your machines. Apologies for the last patch. This patch should work though. Best, Shubham Bansal On Wed, May 24, 2017 at 4:55 AM, Andrew Lunn wrote: > root@qnap:~# test_bpf: #0 TAX jited:0 241 466 241 PASS > test_bpf: #1 TXA jited:1 51 117 51 PASS > test_bpf: #2 ADD_SUB_MUL_K jited:0 167 PASS > test_bpf: #3 DIV_MOD_KX jited:0 571 PASS > test_bpf: #4 AND_OR_LSH_K jited:1 54 54 PASS > test_bpf: #5 LD_IMM_0 jited:1 45 PASS > test_bpf: #6 LD_IND jited:0 143 143 143 PASS > test_bpf: #7 LD_ABS jited:0 120 133 120 PASS > test_bpf: #8 LD_ABS_LL > Unable to handle kernel paging request at virtual address 9e096420 > pgd = daa3 > [9e096420] *pgd= > Internal error: Oops: 805 [#1] PREEMPT ARM > Modules linked in: test_bpf(+) [last unloaded: test_bpf] > CPU: 0 PID: 1886 Comm: modprobe Not tainted > 4.12.0-rc2-00275-g17a0ff4ded06-dirty #1784 > Hardware name: Marvell Kirkwood (Flattened Device Tree) > task: df7d4ba0 task.stack: de738000 > PC is at imm_offset+0xa4/0x108 > LR is at 0x8 > pc : []lr : [<0008>]psr: 6013 > sp : de739c6c ip : 002c fp : 0003 > r10: de739cf8 r9 : e1356000 r8 : 001c > r7 : de59c840 r6 : de59c840 r5 : bf2c2944 r4 : > r3 : dedd3adc r2 : dedd3adc r1 : de739cf8 r0 : ffe0 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > Control: 0005397f Table: 1aa3 DAC: 0051 > Process modprobe (pid: 1886, stack limit = 0xde738190) > Stack: (0xde739c6c to 0xde73a000) > 9c60:0001 0030 0003 c05c5d5e c001a560 > 9c80: de739cf4 e1356038 c05c5d34 ffe0 c05c5d42 > 9ca0: 001a e1356000 5e3b2a64 0f04 e1356000 > 9cc0: e1356000 c078105c 00f8 bf2c2000 bf1661c0 c001c64c > 9ce0: de57f0c8 0008 0002 de739d54 0eec bf2c2944 e1356000 001c > 9d00: 002c 0038 0001 de59c9a0 bf2c2944 00040008 de59c840 > 9d20: e1356000 de739d50 de57f0c0 0005 de59c9a0 0001 c008fb98 > 9d40: e1356000 e1356000 de57f0c0 c04a8384 0008 e1356000 de739dd8 > 9d60: e1356000 0028 de739dd4 bf165140 bf1661c0 c04a84d0 > 9d80: 0005 e1354000 bf1651c8 e1354000 bf2af218 dedcfd20 e000 > 9da0: df45ef80 bf1651c4 0008 0008 0003 0008 0003 > 9dc0: bf1650a5 bf165144 79f5179d 004e e1354000 0005 bf1651c8 > 9de0: e000 bf2af000 de57f9e4 0001 bf2acee0 c007aa88 > 9e00: 0124 c0009738 0001 dfbe78b0 c07c25ac 0080007f > 9e20: dfbe78a4 001f dffc3d60 de738000 df401f00 > 9e40: de56b080 c007d6e0 00016acf c007aa88 bf2acee0 0001 de59c280 0001 > 9e60: bf2acee0 c00a1548 0001 de57f9c0 de739f54 0001 de57f9c0 c007d6e8 > 9e80: bf2aceec 7fff bf2acee0 c007afd4 de739f48 bf2acf28 > 9ea0: bf2ad074 e1344928 c05c76a8 bf2aceec de739f44 c00f6fa8 > 9ec0: 001879a0 c00f7684 > 9ee0: > 9f00: 7fff 0003 7f59f510 017b c000a544 > 9f20: de738000 c007de58 7fff 0003 > 9f40: e11bd000 001879a0 0874 e11bd000 001879a0 e13441d0 > 9f60: e1343ff0 e1337960 00154550 001547c0 14ec > 9f80: 002f 0030 001b 0015 ca81c300 7f5b2810 > 9fa0: c000a3a0 ca81c300 7f5b2810 0003 7f59f510 7f59fd00 > 9fc0: ca81c300 7f5b2810 017b 7f59f510 7f5b21d0 > 9fe0: bee273a0 bee27390 7f593acc b6ed1130 6010 0003 > [] (imm_offset) from [] (build_body+0x5164/0x70ec) > [] (build_body) from [] (bpf_int_jit_compile+0x160/0x314) > [] (bpf_int_jit_compile) from [] > (bpf_prog_select_runtime+0x14/0x124) > [] (bpf_prog_select_runtime) from [] > (bpf_prepare_filter+0x7b0/0x888) > [] (bpf_prepare_filter) from [] > (bpf_prog_create+0x74/0xa4) > [] (bpf_prog_create) from [] (test_bpf_init+0x218/0x77c > [test_bpf]) > [] (test_bpf_init [test_bpf]) from [] > (do_one_initcall+0x40/0x178) > [] (do_one_initcall) from [] (do_init_module+0x58/0x1bc) > [] (do_init_module) from [] (load_module+0x1ae0/0x2050) > [] (load_module) from [] (SyS_finit_module+0xa4/0xb8) > [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x38) > > Looking at the .lst file: > > /* constants go just after the epilogue */ > offset = ctx->offsets[ctx->prog->len]; > c0015054: e591c000ldr ip, [r1] > c0015058: e5912018ldr r2, [r1, #24] > offset += ctx->prologue_bytes; > offset += ctx->epilogue_bytes; > c001505c: e1d132b0ldrhr3, [r1, #32] > of
Re: [PATCH] RFC: arm: eBPF JIT compiler
root@qnap:~# test_bpf: #0 TAX jited:0 241 466 241 PASS test_bpf: #1 TXA jited:1 51 117 51 PASS test_bpf: #2 ADD_SUB_MUL_K jited:0 167 PASS test_bpf: #3 DIV_MOD_KX jited:0 571 PASS test_bpf: #4 AND_OR_LSH_K jited:1 54 54 PASS test_bpf: #5 LD_IMM_0 jited:1 45 PASS test_bpf: #6 LD_IND jited:0 143 143 143 PASS test_bpf: #7 LD_ABS jited:0 120 133 120 PASS test_bpf: #8 LD_ABS_LL Unable to handle kernel paging request at virtual address 9e096420 pgd = daa3 [9e096420] *pgd= Internal error: Oops: 805 [#1] PREEMPT ARM Modules linked in: test_bpf(+) [last unloaded: test_bpf] CPU: 0 PID: 1886 Comm: modprobe Not tainted 4.12.0-rc2-00275-g17a0ff4ded06-dirty #1784 Hardware name: Marvell Kirkwood (Flattened Device Tree) task: df7d4ba0 task.stack: de738000 PC is at imm_offset+0xa4/0x108 LR is at 0x8 pc : []lr : [<0008>]psr: 6013 sp : de739c6c ip : 002c fp : 0003 r10: de739cf8 r9 : e1356000 r8 : 001c r7 : de59c840 r6 : de59c840 r5 : bf2c2944 r4 : r3 : dedd3adc r2 : dedd3adc r1 : de739cf8 r0 : ffe0 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 0005397f Table: 1aa3 DAC: 0051 Process modprobe (pid: 1886, stack limit = 0xde738190) Stack: (0xde739c6c to 0xde73a000) 9c60:0001 0030 0003 c05c5d5e c001a560 9c80: de739cf4 e1356038 c05c5d34 ffe0 c05c5d42 9ca0: 001a e1356000 5e3b2a64 0f04 e1356000 9cc0: e1356000 c078105c 00f8 bf2c2000 bf1661c0 c001c64c 9ce0: de57f0c8 0008 0002 de739d54 0eec bf2c2944 e1356000 001c 9d00: 002c 0038 0001 de59c9a0 bf2c2944 00040008 de59c840 9d20: e1356000 de739d50 de57f0c0 0005 de59c9a0 0001 c008fb98 9d40: e1356000 e1356000 de57f0c0 c04a8384 0008 e1356000 de739dd8 9d60: e1356000 0028 de739dd4 bf165140 bf1661c0 c04a84d0 9d80: 0005 e1354000 bf1651c8 e1354000 bf2af218 dedcfd20 e000 9da0: df45ef80 bf1651c4 0008 0008 0003 0008 0003 9dc0: bf1650a5 bf165144 79f5179d 004e e1354000 0005 bf1651c8 9de0: e000 bf2af000 de57f9e4 0001 bf2acee0 c007aa88 9e00: 0124 c0009738 0001 dfbe78b0 c07c25ac 0080007f 9e20: dfbe78a4 001f dffc3d60 de738000 df401f00 9e40: de56b080 c007d6e0 00016acf c007aa88 bf2acee0 0001 de59c280 0001 9e60: bf2acee0 c00a1548 0001 de57f9c0 de739f54 0001 de57f9c0 c007d6e8 9e80: bf2aceec 7fff bf2acee0 c007afd4 de739f48 bf2acf28 9ea0: bf2ad074 e1344928 c05c76a8 bf2aceec de739f44 c00f6fa8 9ec0: 001879a0 c00f7684 9ee0: 9f00: 7fff 0003 7f59f510 017b c000a544 9f20: de738000 c007de58 7fff 0003 9f40: e11bd000 001879a0 0874 e11bd000 001879a0 e13441d0 9f60: e1343ff0 e1337960 00154550 001547c0 14ec 9f80: 002f 0030 001b 0015 ca81c300 7f5b2810 9fa0: c000a3a0 ca81c300 7f5b2810 0003 7f59f510 7f59fd00 9fc0: ca81c300 7f5b2810 017b 7f59f510 7f5b21d0 9fe0: bee273a0 bee27390 7f593acc b6ed1130 6010 0003 [] (imm_offset) from [] (build_body+0x5164/0x70ec) [] (build_body) from [] (bpf_int_jit_compile+0x160/0x314) [] (bpf_int_jit_compile) from [] (bpf_prog_select_runtime+0x14/0x124) [] (bpf_prog_select_runtime) from [] (bpf_prepare_filter+0x7b0/0x888) [] (bpf_prepare_filter) from [] (bpf_prog_create+0x74/0xa4) [] (bpf_prog_create) from [] (test_bpf_init+0x218/0x77c [test_bpf]) [] (test_bpf_init [test_bpf]) from [] (do_one_initcall+0x40/0x178) [] (do_one_initcall) from [] (do_init_module+0x58/0x1bc) [] (do_init_module) from [] (load_module+0x1ae0/0x2050) [] (load_module) from [] (SyS_finit_module+0xa4/0xb8) [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x38) Looking at the .lst file: /* constants go just after the epilogue */ offset = ctx->offsets[ctx->prog->len]; c0015054: e591c000ldr ip, [r1] c0015058: e5912018ldr r2, [r1, #24] offset += ctx->prologue_bytes; offset += ctx->epilogue_bytes; c001505c: e1d132b0ldrhr3, [r1, #32] offset = ctx->offsets[ctx->prog->len]; c0015060: e59ce008ldr lr, [ip, #8] offset += ctx->epilogue_bytes; c0015064: e591c008ldr ip, [r1, #8] c0015068: 0591501cldreq r5, [r1, #28] offset = ctx->offsets[ctx->prog->len]; c001506c: e792210eldr r2, [r2, lr, lsl #2] offset += ctx->epilogue_bytes; c0015070: e083300cadd r3
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Andrew, I am attaching the additional patch to make it work for ARMv5 as well. Let me know if you find any issues with this. Please apply 0002-Editted-for-ARMv5-compilation.patch after applying the first patch. Best, Shubham Bansal On Wed, May 24, 2017 at 2:16 AM, Andrew Lunn wrote: > On Wed, May 24, 2017 at 12:03:53AM +0530, Shubham Bansal wrote: >> The JIT compiler emits ARM 32 bit instructions. Currently, It supports >> eBPF only. Classic BPF is supported because of the conversion by BPF >> core. > > make mvebu_v5_defconfig > > make -s -j 16 > arch/arm/net/bpf_jit_32.c: In function emit_rev16: > arch/arm/net/bpf_jit_32.c:1019:7: error: implicit declaration of function > ARM_MOV_S [-Werror=implicit-function-declaration] > emit(ARM_MOV_S(tmp2[0], rn, SRTYPE_LSR, 8), ctx); >^ > arch/arm/net/bpf_jit_32.c: In function emit_rev32: > arch/arm/net/bpf_jit_32.c:1037:36: error: macro "ARM_MOV_I" passed 3 > arguments, but takes just 2 > emit(ARM_MOV_I(tmp2[1], rn, 0xff00), ctx); > ^ > arch/arm/net/bpf_jit_32.c:1037:7: error: ARM_MOV_I undeclared (first use in > this function) > emit(ARM_MOV_I(tmp2[1], rn, 0xff00), ctx); >^ > arch/arm/net/bpf_jit_32.c:1037:7: note: each undeclared identifier is > reported only once for each function it appears in > arch/arm/net/bpf_jit_32.c:1039:41: error: macro "ARM_MOV_I" passed 3 > arguments, but takes just 2 > emit(ARM_MOV_I(tmp2[0], tmp2[0], 0xff00), ctx); > ^ > arch/arm/net/bpf_jit_32.c: In function build_insn: > arch/arm/net/bpf_jit_32.c:1393:30: error: macro "ARM_AND_R" requires 3 > arguments, but only 2 given > emit(ARM_AND_R(rt, tmp2[1]), ctx); > ^ > arch/arm/net/bpf_jit_32.c:1393:9: error: ARM_AND_R undeclared (first use in > this function) > emit(ARM_AND_R(rt, tmp2[1]), ctx); > > Andrew 0002-Editted-for-ARMv5-compilation.patch Description: Binary data
Re: [PATCH] RFC: arm: eBPF JIT compiler
On Wed, May 24, 2017 at 12:03:53AM +0530, Shubham Bansal wrote: > The JIT compiler emits ARM 32 bit instructions. Currently, It supports > eBPF only. Classic BPF is supported because of the conversion by BPF > core. > > JIT is enabled with > > echo 1 > /proc/sys/net/core/bpf_jit_enable > > Constant Blinding can be enabled along with JIT using > > echo 1 > /proc/sys/net/core/bpf_jit_enable > echo 2 > /proc/sys/net/core/bpf_jit_harden > > See Documentation/networking/filter.txt for more information. > Tested on ARMv7 with CONFIG_FRAME_POINTER enabled. > > Results: > > 1. Interpreter: > > [ 93.551176] test_bpf: Summary: 314 PASSED, 0 FAILED, [0/306 JIT'ed] > > 2. JIT enabled: > > [ 92.913931] test_bpf: Summary: 314 PASSED, 0 FAILED, [278/306 JIT'ed] > > 3. JIT + blinding enabled: > > [ 109.414506] test_bpf: Summary: 314 PASSED, 0 FAILED, [278/306 JIT'ed] Hi Shubham Is there a HOWTO or a README somewhere about running the tests? I have a few ARMv5 platforms i can run tests on. Thanks Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Andrew, I think I forgot to compile it for ARMv5. Let me send the patch again in few minutes. I appreciate the help. Best, Shubham Bansal On Wed, May 24, 2017 at 2:16 AM, Andrew Lunn wrote: > On Wed, May 24, 2017 at 12:03:53AM +0530, Shubham Bansal wrote: >> The JIT compiler emits ARM 32 bit instructions. Currently, It supports >> eBPF only. Classic BPF is supported because of the conversion by BPF >> core. > > make mvebu_v5_defconfig > > make -s -j 16 > arch/arm/net/bpf_jit_32.c: In function emit_rev16: > arch/arm/net/bpf_jit_32.c:1019:7: error: implicit declaration of function > ARM_MOV_S [-Werror=implicit-function-declaration] > emit(ARM_MOV_S(tmp2[0], rn, SRTYPE_LSR, 8), ctx); >^ > arch/arm/net/bpf_jit_32.c: In function emit_rev32: > arch/arm/net/bpf_jit_32.c:1037:36: error: macro "ARM_MOV_I" passed 3 > arguments, but takes just 2 > emit(ARM_MOV_I(tmp2[1], rn, 0xff00), ctx); > ^ > arch/arm/net/bpf_jit_32.c:1037:7: error: ARM_MOV_I undeclared (first use in > this function) > emit(ARM_MOV_I(tmp2[1], rn, 0xff00), ctx); >^ > arch/arm/net/bpf_jit_32.c:1037:7: note: each undeclared identifier is > reported only once for each function it appears in > arch/arm/net/bpf_jit_32.c:1039:41: error: macro "ARM_MOV_I" passed 3 > arguments, but takes just 2 > emit(ARM_MOV_I(tmp2[0], tmp2[0], 0xff00), ctx); > ^ > arch/arm/net/bpf_jit_32.c: In function build_insn: > arch/arm/net/bpf_jit_32.c:1393:30: error: macro "ARM_AND_R" requires 3 > arguments, but only 2 given > emit(ARM_AND_R(rt, tmp2[1]), ctx); > ^ > arch/arm/net/bpf_jit_32.c:1393:9: error: ARM_AND_R undeclared (first use in > this function) > emit(ARM_AND_R(rt, tmp2[1]), ctx); > > Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
On Wed, May 24, 2017 at 12:03:53AM +0530, Shubham Bansal wrote: > The JIT compiler emits ARM 32 bit instructions. Currently, It supports > eBPF only. Classic BPF is supported because of the conversion by BPF > core. make mvebu_v5_defconfig make -s -j 16 arch/arm/net/bpf_jit_32.c: In function emit_rev16: arch/arm/net/bpf_jit_32.c:1019:7: error: implicit declaration of function ARM_MOV_S [-Werror=implicit-function-declaration] emit(ARM_MOV_S(tmp2[0], rn, SRTYPE_LSR, 8), ctx); ^ arch/arm/net/bpf_jit_32.c: In function emit_rev32: arch/arm/net/bpf_jit_32.c:1037:36: error: macro "ARM_MOV_I" passed 3 arguments, but takes just 2 emit(ARM_MOV_I(tmp2[1], rn, 0xff00), ctx); ^ arch/arm/net/bpf_jit_32.c:1037:7: error: ARM_MOV_I undeclared (first use in this function) emit(ARM_MOV_I(tmp2[1], rn, 0xff00), ctx); ^ arch/arm/net/bpf_jit_32.c:1037:7: note: each undeclared identifier is reported only once for each function it appears in arch/arm/net/bpf_jit_32.c:1039:41: error: macro "ARM_MOV_I" passed 3 arguments, but takes just 2 emit(ARM_MOV_I(tmp2[0], tmp2[0], 0xff00), ctx); ^ arch/arm/net/bpf_jit_32.c: In function build_insn: arch/arm/net/bpf_jit_32.c:1393:30: error: macro "ARM_AND_R" requires 3 arguments, but only 2 given emit(ARM_AND_R(rt, tmp2[1]), ctx); ^ arch/arm/net/bpf_jit_32.c:1393:9: error: ARM_AND_R undeclared (first use in this function) emit(ARM_AND_R(rt, tmp2[1]), ctx); Andrew
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi Russell,
On Wed, May 24, 2017 at 12:30 AM, Russell King - ARM Linux
wrote:
> Hi,
>
> On Wed, May 24, 2017 at 12:03:53AM +0530, Shubham Bansal wrote:
>> The JIT compiler emits ARM 32 bit instructions. Currently, It supports
>> eBPF only. Classic BPF is supported because of the conversion by BPF
>> core.
>>
>> JIT is enabled with
>>
>> echo 1 > /proc/sys/net/core/bpf_jit_enable
>>
>> Constant Blinding can be enabled along with JIT using
>>
>> echo 1 > /proc/sys/net/core/bpf_jit_enable
>> echo 2 > /proc/sys/net/core/bpf_jit_harden
>>
>> See Documentation/networking/filter.txt for more information.
>> Tested on ARMv7 with CONFIG_FRAME_POINTER enabled.
>
> What is this patch actually doing?
This is the first implementation of eBPF JIT for ARM.
>
> The commit message doesn't describe what changes this patch is doing,
> and it needs to. Presumably, it's adding support for eBPF?
Apologies. I thought commit message was good enough to understand. I
will resend the patch if needed.
Although, Its an RFC. I am requesting the community for with testing
and suggestions.
>
> If that's so, doesn't it need to change us from selecting HAVE_CBPF_JIT
> to selecting HAVE_EBPF_JIT ?
This patch is only for comments and testing. I thought, KConfig
changes wouldn't be needed unless
the patch is accepted.
>
> What about cases where the frame pointer is not enabled?If that's
> not supported then shouldn't the Kconfig be adjusted? What about
> users who are using cBPF without the frame pointer enabled?
I have tested it with and without the frame pointer as indicated in
the results shown in the mail.
>
> I haven't been able to go through the patch analysing it fully, but
> what I have read doesn't give me any immediate concerns. Only one
> spelling mistake stood out.
>
> Some things that I'm wondering though - what about endian issues?
> LDRD, for example, takes two registers, in ARM mode, these registers
> must be an even-odd pair. The even register is loaded from at the
> lowest address, the odd register from the higher address. This means
> when loading a BE value, the most significant word is in the even
> numbered register and the least significant word is in the odd numbered
> register. For LE values, the even numbered register contains the least
> significant word. Are we properly handling issues like this in all
> places?
Actually I haven't tested it with BE but tested it LE as I wasn't able
to run qemu to test it properly for BE.
I request anyone who has information on how to test it to help me with it.
>
>> +static const u8 bpf2a32[][2] = {
>> + /* return value from in-kernel function, and exit value from eBPF */
>> + [BPF_REG_0] = {ARM_R1, ARM_R0},
>> + /* arguments from eBPF program to in-kernel function */
>> + [BPF_REG_1] = {ARM_R3, ARM_R2},
>> + /* Stored on stack scratch space */
>> + [BPF_REG_2] = {STACK_OFFSET(0), STACK_OFFSET(4)},
>> + [BPF_REG_3] = {STACK_OFFSET(8), STACK_OFFSET(12)},
>> + [BPF_REG_4] = {STACK_OFFSET(16), STACK_OFFSET(20)},
>> + [BPF_REG_5] = {STACK_OFFSET(24), STACK_OFFSET(28)},
>> + /* callee saved registers that in-kernel function will preserve */
>> + [BPF_REG_6] = {ARM_R5, ARM_R4},
>> + /* Stored on stack scratch space */
>> + [BPF_REG_7] = {STACK_OFFSET(32), STACK_OFFSET(36)},
>> + [BPF_REG_8] = {STACK_OFFSET(40), STACK_OFFSET(44)},
>> + [BPF_REG_9] = {STACK_OFFSET(48), STACK_OFFSET(52)},
>> + /* Read only Frame Pointer to access Stack */
>> + [BPF_REG_FP] = {STACK_OFFSET(56), STACK_OFFSET(60)},
>> + /* Temperory Register for internal BPF JIT, can be used
>
> "Temporary"
I will correct that right away.
Thanks for the suggestions Russell.
-Shubham
Re: [PATCH] RFC: arm: eBPF JIT compiler
Hi,
On Wed, May 24, 2017 at 12:03:53AM +0530, Shubham Bansal wrote:
> The JIT compiler emits ARM 32 bit instructions. Currently, It supports
> eBPF only. Classic BPF is supported because of the conversion by BPF
> core.
>
> JIT is enabled with
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
>
> Constant Blinding can be enabled along with JIT using
>
> echo 1 > /proc/sys/net/core/bpf_jit_enable
> echo 2 > /proc/sys/net/core/bpf_jit_harden
>
> See Documentation/networking/filter.txt for more information.
> Tested on ARMv7 with CONFIG_FRAME_POINTER enabled.
What is this patch actually doing?
The commit message doesn't describe what changes this patch is doing,
and it needs to. Presumably, it's adding support for eBPF?
If that's so, doesn't it need to change us from selecting HAVE_CBPF_JIT
to selecting HAVE_EBPF_JIT ?
What about cases where the frame pointer is not enabled? If that's
not supported then shouldn't the Kconfig be adjusted? What about
users who are using cBPF without the frame pointer enabled?
I haven't been able to go through the patch analysing it fully, but
what I have read doesn't give me any immediate concerns. Only one
spelling mistake stood out.
Some things that I'm wondering though - what about endian issues?
LDRD, for example, takes two registers, in ARM mode, these registers
must be an even-odd pair. The even register is loaded from at the
lowest address, the odd register from the higher address. This means
when loading a BE value, the most significant word is in the even
numbered register and the least significant word is in the odd numbered
register. For LE values, the even numbered register contains the least
significant word. Are we properly handling issues like this in all
places?
> +static const u8 bpf2a32[][2] = {
> + /* return value from in-kernel function, and exit value from eBPF */
> + [BPF_REG_0] = {ARM_R1, ARM_R0},
> + /* arguments from eBPF program to in-kernel function */
> + [BPF_REG_1] = {ARM_R3, ARM_R2},
> + /* Stored on stack scratch space */
> + [BPF_REG_2] = {STACK_OFFSET(0), STACK_OFFSET(4)},
> + [BPF_REG_3] = {STACK_OFFSET(8), STACK_OFFSET(12)},
> + [BPF_REG_4] = {STACK_OFFSET(16), STACK_OFFSET(20)},
> + [BPF_REG_5] = {STACK_OFFSET(24), STACK_OFFSET(28)},
> + /* callee saved registers that in-kernel function will preserve */
> + [BPF_REG_6] = {ARM_R5, ARM_R4},
> + /* Stored on stack scratch space */
> + [BPF_REG_7] = {STACK_OFFSET(32), STACK_OFFSET(36)},
> + [BPF_REG_8] = {STACK_OFFSET(40), STACK_OFFSET(44)},
> + [BPF_REG_9] = {STACK_OFFSET(48), STACK_OFFSET(52)},
> + /* Read only Frame Pointer to access Stack */
> + [BPF_REG_FP] = {STACK_OFFSET(56), STACK_OFFSET(60)},
> + /* Temperory Register for internal BPF JIT, can be used
"Temporary"
