On 2/19/20 8:56 AM, Daniel Borkmann wrote:
On 2/19/20 1:42 AM, Yonghong Song wrote:
The latest llvm supports cpu version v3, which is cpu version v1
plus some additional 64bit jmp insns and 32bit jmp insn support.
In selftests/bpf Makefile, the llvm flag -mcpu=probe did runtime
probe into the host system. Depending on compilation environments,
it is possible that runtime probe may fail, e.g., due to
memlock issue. This will cause generated code with cpu version v1.
But those are tiny BPF progs that LLVM is probing. If memlock is not
sufficient, should it try to bump the limit with the diff needed and
only if that fails as well then it bails out to v1.
The selftest is also trying to test the latest kernel, so we want
to keep cpu version as v3 always?
There are cases e.g., compilation on a devserver and selftests running
in a VM. The linux directory is shared between the host and the qemu.
qemu runs latest kernel and devserver's old kernel may have small
memlock or in unlikely case the old kernel may simply not supporting the
cpu v3, so in such cases, maybe forcing cpu=v3 is better since this is
what we intend to test?
This may cause confusion as the same compiler and the same C code
generates different byte codes in different environment.
Let us change the llvm flag -mcpu=probe to -mcpu=v3 so the
generated code will be the same regardless of the compilation
environment.
Signed-off-by: Yonghong Song <yhs@xxxxxx>
