From: Tony Ambardar <tony.ambardar@gmail.com>
To: bpf@vger.kernel.org
Cc: Tony Ambardar <tony.ambardar@gmail.com>,
linux-kselftest@vger.kernel.org,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko <mykolal@fb.com>,
Shuah Khan <shuah@kernel.org>,
Ilya Leoshkevich <iii@linux.ibm.com>,
Quentin Monnet <qmo@kernel.org>
Subject: [PATCH bpf-next v5 0/8] libbpf, selftests/bpf: Support cross-endian usage
Date: Tue, 3 Sep 2024 00:32:57 -0700 [thread overview]
Message-ID: <cover.1725347944.git.tony.ambardar@gmail.com> (raw)
Hello all,
This patch series targets a long-standing BPF usability issue - the lack
of general cross-compilation support - by enabling cross-endian usage of
libbpf and bpftool, as well as supporting cross-endian build targets for
selftests/bpf.
Benefits include improved BPF development and testing for embedded systems
based on e.g. big-endian MIPS, more build options e.g for s390x systems,
and better accessibility to the very latest test tools e.g. 'test_progs'.
The series touches many functional areas: BTF.ext handling; object access,
introspection, and linking; generation of normal and "light" skeletons.
Initial development and testing used mips64, since this arch makes
switching the build byte-order trivial and is thus very handy for A/B
testing. However, it lacks some key features (bpf2bpf call, kfuncs, etc)
making for poor selftests/bpf coverage.
Final testing takes the kernel and selftests/bpf cross-built from x86_64
to s390x, and runs the result under QEMU/s390x. That same configuration
could also be used on kernel-patches/bpf CI for regression testing endian
support or perhaps load-sharing s390x builds across x86_64 systems.
This thread includes some background regarding testing on QEMU/s390x and
the generally favourable results:
https://lore.kernel.org/bpf/ZsEcsaa3juxxQBUf@kodidev-ubuntu/
Earlier versions and related discussion of the series are here:
v1: https://lore.kernel.org/bpf/cover.1724216108.git.tony.ambardar@gmail.com/
v2: https://lore.kernel.org/bpf/cover.1724313164.git.tony.ambardar@gmail.com/
v3: https://lore.kernel.org/bpf/cover.1724843049.git.tony.ambardar@gmail.com/
v4: https://lore.kernel.org/bpf/cover.1724976539.git.tony.ambardar@gmail.com/
Feedback and suggestions are welcome!
Best regards,
Tony
Changelog:
---------
v4 -> v5: (feedback from Andrii and Eduard)
- add separate functions to byte-swap info metadata and records, and
ensure ordering so record bswaps occur when metadata is native endian
- use new and existing macros to iterate through info sections/records,
and check embedded record sizes match that of info structs used
- drop use of <cough> evil callbacks
- move setting swapped_endian flag to after byte-swapping functions are
called during initialization, allowing funcs to infer endianness and
drop a 'bool native' call parameter
- simplify byte-swapping macro used to generate light skeleton, and use
internal lib funcs to swap info records instead of assuming all __u32
- change info bswap library funcs to void return
- rework/consolidate new debug statements to reduce their number
- remove some unneeded handling of impossible errors, and drop a safety
check already handled elsewhere
- add and clarify some comments
v3 -> v4:
- fix a use-after-free ELF data-handling error causing rare CI failures
- move bswap functions for func/line/core-relo records to internal header
- use bswap functions also for info blobs in light skeleton
v2 -> v3: (feedback from Andrii)
- improve some log and commit message formatting
- restructure BTF.ext endianness safety checks and byte-swapping
- use BTF.ext info record definitions for swapping, require BTF v1
- follow BTF API implementation more closely for BTF.ext
- explicitly reject loading non-native endianness program into kernel
- simplify linker output byte-order setting
- drop redundant safety checks during linking
- simplify endianness macro and improve blob setup code for light skel
- no unexpected test failures after cross-compiling x86_64 -> s390x
v1 -> v2:
- fixed a light skeleton bug causing test_progs 'map_ptr' failure
- simplified some BTF.ext related endianness logic
- remove an 'inline' usage related to CI checkpatch failure
- improve some formatting noted by checkpatch warnings
- unexpected 'test_progs' failures drop 3 -> 2 (x86_64 to s390x cross)
Tony Ambardar (8):
libbpf: Improve log message formatting
libbpf: Fix header comment typos for BTF.ext
libbpf: Fix output .symtab byte-order during linking
libbpf: Support BTF.ext loading and output in either endianness
libbpf: Support opening bpf objects of either endianness
libbpf: Support linking bpf objects of either endianness
libbpf: Support creating light skeleton of either endianness
selftests/bpf: Support cross-endian building
tools/lib/bpf/bpf_gen_internal.h | 1 +
tools/lib/bpf/btf.c | 242 +++++++++++++++++++++++++--
tools/lib/bpf/btf.h | 3 +
tools/lib/bpf/btf_dump.c | 2 +-
tools/lib/bpf/btf_relocate.c | 2 +-
tools/lib/bpf/gen_loader.c | 191 +++++++++++++++------
tools/lib/bpf/libbpf.c | 57 +++++--
tools/lib/bpf/libbpf.map | 2 +
tools/lib/bpf/libbpf_internal.h | 43 ++++-
tools/lib/bpf/linker.c | 80 +++++++--
tools/lib/bpf/relo_core.c | 2 +-
tools/lib/bpf/skel_internal.h | 3 +-
tools/testing/selftests/bpf/Makefile | 7 +-
13 files changed, 529 insertions(+), 106 deletions(-)
--
2.34.1
next reply other threads:[~2024-09-03 7:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-03 7:32 Tony Ambardar [this message]
2024-09-03 7:32 ` [PATCH bpf-next v5 1/8] libbpf: Improve log message formatting Tony Ambardar
2024-09-03 7:32 ` [PATCH bpf-next v5 2/8] libbpf: Fix header comment typos for BTF.ext Tony Ambardar
2024-09-03 7:33 ` [PATCH bpf-next v5 3/8] libbpf: Fix output .symtab byte-order during linking Tony Ambardar
2024-09-03 7:33 ` [PATCH bpf-next v5 4/8] libbpf: Support BTF.ext loading and output in either endianness Tony Ambardar
2024-09-04 19:48 ` Andrii Nakryiko
2024-09-16 8:21 ` Tony Ambardar
2024-09-03 7:33 ` [PATCH bpf-next v5 5/8] libbpf: Support opening bpf objects of " Tony Ambardar
2024-09-04 19:50 ` Andrii Nakryiko
2024-09-03 7:33 ` [PATCH bpf-next v5 6/8] libbpf: Support linking " Tony Ambardar
2024-09-04 19:51 ` Andrii Nakryiko
2024-09-03 7:33 ` [PATCH bpf-next v5 7/8] libbpf: Support creating light skeleton " Tony Ambardar
2024-09-03 19:57 ` Alexei Starovoitov
2024-09-03 23:52 ` Tony Ambardar
2024-09-03 7:33 ` [PATCH bpf-next v5 8/8] selftests/bpf: Support cross-endian building Tony Ambardar
2024-09-04 5:52 ` Yonghong Song
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=cover.1725347944.git.tony.ambardar@gmail.com \
--to=tony.ambardar@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=iii@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=qmo@kernel.org \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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