Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern And those are generated calls so I don't see how we can fix them. Is this a module ? We should really be linking that stuff directly with the module The interesting thing is that we do build everything except a handful of files with -mminimal-toc unless something's wrong with our main Makefile Can you show the full build command that triggers the above ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote: On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern And those are generated calls so I don't see how we can fix them. Is this a module ? We should really be linking that stuff directly with the module No, it's builtin. The interesting thing is that we do build everything except a handful of files with -mminimal-toc unless something's wrong with our main Makefile Yeah, the top arch Makefile sets it, though we do override it in a few places. I tried removing those overrides and it didn't seem to make any difference. Can you show the full build command that triggers the above ? Well that would be a few MBs of log, but here's an excerpt: make -f scripts/Makefile.build obj=net/openvswitch /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wp,-MD,net/openvswitch/.vport-netdev.o.d -nostdinc -isystem /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/lib/gcc/powerpc64-linux/4.6.3/include -I/home/michael/src/kmk/next/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -include /home/michael/src/kmk/next/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-call ed-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fprofile-arcs -ftest-coverage -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vport_netdev) -DKBUILD_MODNAME=KBUILD_STR(openvswitch) -c -o net/openvswitch/.tmp_vport-netdev.o net/openvswitch/vport-netdev.c if [ -pg = -pg ]; then set -e ; perl /home/michael/src/kmk/next/scripts/recordmcount.pl powerpc little 64 /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objdump /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objcopy /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-s trict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-ld -m elf64ppc /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-nm --synthetic 0 net/openvswitch/vport-netdev.o; fi; And then a whole bunch of calls to ld. So we are at least building that file with -mminimal-toc. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, Jun 21, 2012 at 03:36:01PM +1000, Michael Ellerman wrote: On Wed, 2012-06-20 at 17:50 +1000, Stephen Rothwell wrote: Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word': (.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern Those seem to be caused because we don't have a nop after the call, meaning we can't patch the TOC pointer on the way back. Adding a nop fixes those. But, then I get 32,410 variants of this: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern These functions should not need a TOC in the first place. There is code in the linker (for 64 bit only: bfd/elf64-ppc.c) to automatically generate them whenever they are needed. I suspect you compile with -Os. But I don't think you can use these functions when doing a sibling call since restgpr0_nn implies a return to the caller. restgpr1_nn would be different... And those are generated calls so I don't see how we can fix them. I started building with gcc 4.6.3/binutils 2.22 today. gcc 4.6.0/binutils 2.21 do not produce this error, it produces this instead (which has been happening for a long time): powerpc64-linux-ld: TOC section size exceeds 64k So presumably there's some new error checking that we're hitting, I imagine it was always broken, but now it's being more explicit. I'm not so sure. I suspect gcc, but upgrading gcc and binutils at the same time may not be the wisest... Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 17:07 +1000, Michael Ellerman wrote: On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote: On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern Can you show the full build command that triggers the above ? Well that would be a few MBs of log, but here's an excerpt: make -f scripts/Makefile.build obj=net/openvswitch /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wp,-MD,net/openvswitch/.vport-netdev.o.d -nostdinc -isystem /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/lib/gcc/powerpc64-linux/4.6.3/include -I/home/michael/src/kmk/next/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -include /home/michael/src/kmk/next/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-ca lled-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fprofile-arcs -ftest-coverage -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vport_netdev) -DKBUILD_MODNAME=KBUILD_STR(openvswitch) -c -o net/openvswitch/.tmp_vport-netdev.o net/openvswitch/vport-netdev.c if [ -pg = -pg ]; then set -e ; perl /home/michael/src/kmk/next/scripts/recordmcount.pl powerpc little 64 /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objdump /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-objcopy /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -mno-sched-epilog -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -g -femit-struct-debug-baseonly -pg -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno -strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-ld -m elf64ppc /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-nm --synthetic 0 net/openvswitch/vport-netdev.o; fi; Just for the record it's not the FTRACE stuff (-pg): /opt/cross/gcc-4.6-nolibc/powerpc64-linux/bin/powerpc64-linux-gcc -m64 -Wp,-MD,net/openvswitch/.vport-netdev.o.d -nostdinc -isystem /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/lib/gcc/powerpc64-linux/4.6.3/include -I/home/michael/src/kmk/next/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -include /home/michael/src/kmk/next/include/linux/kconfig.h -D__KERNEL__ -Iarch/powerpc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -msoft-float -pipe -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mtune=power7 -mtune=cell -mno-altivec -mno-vsx -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -Wa,-maltivec -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -femit-struct-debug-baseonly -fno-inline-functions-calle d-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fprofile-arcs -ftest-coverage -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vport_netdev) -DKBUILD_MODNAME=KBUILD_STR(openvswitch) -c -o net/openvswitch/.tmp_vport-netdev.o net/openvswitch/vport-netdev.c And same error. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, Jun 21, 2012 at 05:38:27PM +1000, Michael Ellerman wrote: On Thu, 2012-06-21 at 17:07 +1000, Michael Ellerman wrote: On Thu, 2012-06-21 at 16:24 +1000, Benjamin Herrenschmidt wrote: On Thu, 2012-06-21 at 15:36 +1000, Michael Ellerman wrote: powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern Linker bug. That's not a sibling call, but a normal function return via an out-of-line register restore function. Will fix. I'm a bit surprised to see this with gcc-4.6 though. Or does this gcc-4.6 have some of my recent mainline gcc patches enabling out-of-line save/restore functions for -Os? -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote: Linker bug. That's not a sibling call, but a normal function return via an out-of-line register restore function. I couldn't see how this might be occurring, then I remembered the kernel has this horrible practise of using ld -r to package object files. So linker generated functions might be munged together with other functions. Does this help? (It won't if the kernel is providing its own save/restore functions.) Index: bfd/elf64-ppc.c === RCS file: /cvs/src/src/bfd/elf64-ppc.c,v retrieving revision 1.387 diff -u -p -r1.387 elf64-ppc.c @@ -6494,9 +6494,10 @@ ppc64_elf_func_desc_adjust (bfd *obfd AT /* Provide any missing _save* and _rest* functions. */ htab-sfpr-size = 0; - for (i = 0; i sizeof (funcs) / sizeof (funcs[0]); i++) -if (!sfpr_define (info, funcs[i])) - return FALSE; + if (!info-relocatable) +for (i = 0; i sizeof (funcs) / sizeof (funcs[0]); i++) + if (!sfpr_define (info, funcs[i])) + return FALSE; elf_link_hash_traverse (htab-elf, func_desc_adjust, info); -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kernel panic during kernel module load (powerpc specific part)
--- On Wed, 6/6/12, Steffen Rumler steffen.rumler@nsn.com wrote:
From: Steffen Rumler steffen.rumler@nsn.com
Subject: [PATCH] kernel panic during kernel module load (powerpc specific
part)
To: ext Benjamin Herrenschmidt b...@kernel.crashing.org, pau...@samba.org
Cc: Wrobel Heinz-R39252 r39...@freescale.com, Michael Ellerman
mich...@ellerman.id.au, linuxppc-dev@lists.ozlabs.org
linuxppc-dev@lists.ozlabs.org
Date: Wednesday, June 6, 2012, 7:37 AM
Hi,
The patch below is intended to fix the following problem.
According to the PowerPC EABI specification, the GPR r11 is
assigned
the dedicated function to point to the previous stack
frame.
In the powerpc-specific kernel module loader, do_plt_call()
(in arch/powerpc/kernel/module_32.c), the GPR r11 is also
used
to generate trampoline code.
This combination crashes the kernel, in the following case:
+ The compiler has been generated the prologue and
epilogue,
which is part of the .text section.
+ The compiler has been generated the code for the
module init entry point,
part of the .init.text section (in the case it
is marked with __init).
+ By returning from the module init entry point, the
epilogue is called by doing
a branch instruction.
+ If the epilogue is too far away, a relative branch
instruction cannot be applied.
Instead trampoline code is generated in
do_plt_call(), in order to jump via register.
Unfortunately the code generated by
do_plt_call() destroys the content of GPR r11.
+ Because GPR r11 does not more keep the right stack
frame pointer,
the kernel crashes right after the epilogue.
The fix just uses GPR r12 instead of GPR r11 for generating
the trampoline code.
According to the statements from Freescale, this is also
save from EABI perspective.
I've tested the fix for kernel 2.6.33 on MPC8541.
Signed-off-by: Steffen Rumler steffen.rumler@nsn.com
---
--- orig/arch/powerpc/kernel/module_32.c
2012-06-06 16:04:28.956446788 +0200
+++ new/arch/powerpc/kernel/module_32.c
2012-06-06 16:04:17.746290683 +0200
@@ -187,8 +187,8 @@
static inline int entry_matches(struct ppc_plt_entry
*entry, Elf32_Addr val)
{
- if (entry-jump[0] == 0x3d60 +
((val + 0x8000) 16)
-
entry-jump[1] == 0x396b + (val 0x))
+ if (entry-jump[0] == 0x3d80 +
((val + 0x8000) 16)
+
entry-jump[1] == 0x398c + (val 0x))
return 1;
return 0;
}
@@ -215,10 +215,9 @@
entry++;
}
- /* Stolen from Paul Mackerras as well...
*/
- entry-jump[0] =
0x3d60+((val+0x8000)16); /*
lis r11,sym@ha */
- entry-jump[1] = 0x396b +
(val0x); /* addi r11,r11,sym@l*/
- entry-jump[2] =
0x7d6903a6;
/* mtctr r11 */
+ entry-jump[0] =
0x3d80+((val+0x8000)16); /* lis r12,sym@ha */
+ entry-jump[1] = 0x398c +
(val0x); /* addi
r12,r12,sym@l*/
+ entry-jump[2] = 0x7d8903a6;
/* mtctr r12 */
entry-jump[3] =
0x4e800420;
/* bctr */
DEBUGP(Initialized plt for 0x%x at
%p\n, val, entry);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Hi,
Shouldn't the corresponding ftrace code be updated to match? Perhaps like the
following (untested) patch:
Signed-off-by: Roger Blofeld blofel...@yahoo.com
---
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -245,9 +245,9 @@ __ftrace_make_nop(struct module *mod,
/*
* On PPC32 the trampoline looks like:
-* 0x3d, 0x60, 0x00, 0x00 lis r11,sym@ha
-* 0x39, 0x6b, 0x00, 0x00 addi r11,r11,sym@l
-* 0x7d, 0x69, 0x03, 0xa6 mtctr r11
+* 0x3d, 0x80, 0x00, 0x00 lis r12,sym@ha
+* 0x39, 0x8c, 0x00, 0x00 addi r12,r12,sym@l
+* 0x7d, 0x89, 0x03, 0xa6 mtctr r12
* 0x4e, 0x80, 0x04, 0x20 bctr
*/
@@ -262,9 +262,9 @@ __ftrace_make_nop(struct module *mod,
pr_devel( %08x %08x , jmp[0], jmp[1]);
/* verify that this is what we expect it to be */
- if (((jmp[0] 0x) != 0x3d60) ||
- ((jmp[1] 0x) != 0x396b) ||
- (jmp[2] != 0x7d6903a6) ||
+ if (((jmp[0] 0x) != 0x3d80) ||
+ ((jmp[1] 0x) != 0x398c) ||
+ (jmp[2] != 0x7d8903a6) ||
(jmp[3] != 0x4e800420)) {
printk(KERN_ERR Not a trampoline\n);
return -EINVAL;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (powerpc related)
On Thu, 2012-06-21 at 21:13 +0930, Alan Modra wrote: On Thu, Jun 21, 2012 at 08:18:39PM +0930, Alan Modra wrote: Linker bug. That's not a sibling call, but a normal function return via an out-of-line register restore function. I couldn't see how this might be occurring, then I remembered the kernel has this horrible practise of using ld -r to package object files. So linker generated functions might be munged together with other functions. Does this help? (It won't if the kernel is providing its own save/restore functions.) The kernel does provide its own AIUI. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix BPF_JIT code to link with multiple TOCs
If the kernel is big enough (eg. allyesconfig), the linker may need to switch TOCs when calling from the BPF JIT code out to the external helpers (skb_copy_bits() bpf_internal_load_pointer_neg_helper()). In order to do that we need to leave space after the bl for the linker to insert a reload of our TOC pointer. Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/net/bpf_jit_64.S |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/net/bpf_jit_64.S b/arch/powerpc/net/bpf_jit_64.S index 55ba385..7d3a3b5 100644 --- a/arch/powerpc/net/bpf_jit_64.S +++ b/arch/powerpc/net/bpf_jit_64.S @@ -105,6 +105,7 @@ sk_load_byte_msh_positive_offset: mr r4, r_addr; \ li r6, SIZE; \ bl skb_copy_bits; \ + nop;\ /* R3 = 0 on success */ \ addir1, r1, BPF_PPC_SLOWPATH_FRAME; \ ld r0, 16(r1); \ @@ -156,6 +157,7 @@ bpf_slow_path_byte_msh: mr r4, r_addr; \ li r5, SIZE; \ bl bpf_internal_load_pointer_neg_helper; \ + nop;\ /* R3 != 0 on success */\ addir1, r1, BPF_PPC_SLOWPATH_FRAME; \ ld r0, 16(r1); \ -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Turn on BPF_JIT in ppc64_defconfig
Matt added BPF_JIT support in commit 0ca87f05, but currently none of our defconfigs build it. Turn that sucker on. Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/configs/ppc64_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig index c1442a3..a637ee7 100644 --- a/arch/powerpc/configs/ppc64_defconfig +++ b/arch/powerpc/configs/ppc64_defconfig @@ -489,3 +489,4 @@ CONFIG_VIRTUALIZATION=y CONFIG_KVM_BOOK3S_64=m CONFIG_KVM_BOOK3S_64_HV=y CONFIG_VHOST_NET=m +CONFIG_BPF_JIT=y -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
