* [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
Patch 1 is to enable cross platform testing for local vmtest. The
remaining patch adds local vmtest support for riscv64. It relies on
commit [0] [1] for better regression.
We can now perform cross platform testing for riscv64 bpf using the
following command:
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
The test platform is x86_64 architecture, and the versions of relevant
components are as follows:
QEMU: 8.2.0
CLANG: 17.0.6 (align to BPF CI)
OpenSBI: 1.3.1 (default by QEMU)
ROOTFS: ubuntu jammy (generated by [2])
Link: https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493 [0]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=443574b033876c85 [1]
Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [2]
Pu Lehui (5):
selftests/bpf: Enable cross platform testing for local vmtest
riscv, bpf: Relax restrictions on Zbb instructions
selftests/bpf: Add config.riscv64
selftests/bpf: Add DENYLIST.riscv64
selftests/bpf: Add riscv64 configurations to local vmtest
arch/riscv/net/bpf_jit.h | 2 +-
tools/testing/selftests/bpf/DENYLIST.riscv64 | 5 ++
tools/testing/selftests/bpf/config.riscv64 | 85 ++++++++++++++++++++
tools/testing/selftests/bpf/vmtest.sh | 48 ++++++++---
4 files changed, 127 insertions(+), 13 deletions(-)
create mode 100644 tools/testing/selftests/bpf/DENYLIST.riscv64
create mode 100644 tools/testing/selftests/bpf/config.riscv64
--
2.34.1
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
Patch 1 is to enable cross platform testing for local vmtest. The
remaining patch adds local vmtest support for riscv64. It relies on
commit [0] [1] for better regression.
We can now perform cross platform testing for riscv64 bpf using the
following command:
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
The test platform is x86_64 architecture, and the versions of relevant
components are as follows:
QEMU: 8.2.0
CLANG: 17.0.6 (align to BPF CI)
OpenSBI: 1.3.1 (default by QEMU)
ROOTFS: ubuntu jammy (generated by [2])
Link: https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493 [0]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=443574b033876c85 [1]
Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [2]
Pu Lehui (5):
selftests/bpf: Enable cross platform testing for local vmtest
riscv, bpf: Relax restrictions on Zbb instructions
selftests/bpf: Add config.riscv64
selftests/bpf: Add DENYLIST.riscv64
selftests/bpf: Add riscv64 configurations to local vmtest
arch/riscv/net/bpf_jit.h | 2 +-
tools/testing/selftests/bpf/DENYLIST.riscv64 | 5 ++
tools/testing/selftests/bpf/config.riscv64 | 85 ++++++++++++++++++++
tools/testing/selftests/bpf/vmtest.sh | 48 ++++++++---
4 files changed, 127 insertions(+), 13 deletions(-)
create mode 100644 tools/testing/selftests/bpf/DENYLIST.riscv64
create mode 100644 tools/testing/selftests/bpf/config.riscv64
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH bpf-next 1/5] selftests/bpf: Enable cross platform testing for local vmtest
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-28 12:49 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
The variable $ARCH in the current script is platform semantics, not
kernel semantics. Rename it to $PLATFORM so that we can easily use $ARCH
in cross-compilation. For now, Using PLATFORM= and CROSS_COMPILE=
options will enable cross platform testing:
PLATFORM=<platform> CROSS_COMPILE=<toolchain> vmtest.sh -- ./test_progs
Meanwhile, some descriptions have been corrected.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/vmtest.sh | 40 +++++++++++++++++++--------
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/bpf/vmtest.sh b/tools/testing/selftests/bpf/vmtest.sh
index 65d14f3bbe30..825149a905e5 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -4,28 +4,34 @@
set -u
set -e
-# This script currently only works for x86_64 and s390x, as
-# it is based on the VM image used by the BPF CI, which is
+# This script currently only works for the following platforms,
+# as it is based on the VM image used by the BPF CI, which is
# available only for these architectures.
-ARCH="$(uname -m)"
-case "${ARCH}" in
+PLATFORM="${PLATFORM:-$(uname -m)}"
+case "${PLATFORM}" in
s390x)
QEMU_BINARY=qemu-system-s390x
QEMU_CONSOLE="ttyS1"
- QEMU_FLAGS=(-smp 2)
+ HOST_FLAGS=(-smp 2 -enable-kvm)
+ CROSS_FLAGS=(-smp 2)
BZIMAGE="arch/s390/boot/vmlinux"
+ ARCH="s390"
;;
x86_64)
QEMU_BINARY=qemu-system-x86_64
QEMU_CONSOLE="ttyS0,115200"
- QEMU_FLAGS=(-cpu host -smp 8)
+ HOST_FLAGS=(-cpu host -enable-kvm -smp 8)
+ CROSS_FLAGS=(-smp 8)
BZIMAGE="arch/x86/boot/bzImage"
+ ARCH="x86"
;;
aarch64)
QEMU_BINARY=qemu-system-aarch64
QEMU_CONSOLE="ttyAMA0,115200"
- QEMU_FLAGS=(-M virt,gic-version=3 -cpu host -smp 8)
+ HOST_FLAGS=(-M virt,gic-version=3 -cpu host -enable-kvm -smp 8)
+ CROSS_FLAGS=(-M virt,gic-version=3 -cpu cortex-a76 -smp 8)
BZIMAGE="arch/arm64/boot/Image"
+ ARCH="arm64"
;;
*)
echo "Unsupported architecture"
@@ -38,7 +44,7 @@ ROOTFS_IMAGE="root.img"
OUTPUT_DIR="$HOME/.bpf_selftests"
KCONFIG_REL_PATHS=("tools/testing/selftests/bpf/config"
"tools/testing/selftests/bpf/config.vm"
- "tools/testing/selftests/bpf/config.${ARCH}")
+ "tools/testing/selftests/bpf/config.${PLATFORM}")
INDEX_URL="https://raw.githubusercontent.com/libbpf/ci/master/INDEX"
NUM_COMPILE_JOBS="$(nproc)"
LOG_FILE_BASE="$(date +"bpf_selftests.%Y-%m-%d_%H-%M-%S")"
@@ -58,6 +64,10 @@ tools/testing/selftests/bpf. e.g:
If no command is specified and a debug shell (-s) is not requested,
"${DEFAULT_COMMAND}" will be run by default.
+Using PLATFORM= and CROSS_COMPILE= options will enable cross platform testing:
+
+ PLATFORM=<platform> CROSS_COMPILE=<toolchain> $0 -- ./test_progs -t test_lsm
+
If you build your kernel using KBUILD_OUTPUT= or O= options, these
can be passed as environment variables to the script:
@@ -109,7 +119,7 @@ newest_rootfs_version()
{
{
for file in "${!URLS[@]}"; do
- if [[ $file =~ ^"${ARCH}"/libbpf-vmtest-rootfs-(.*)\.tar\.zst$ ]]; then
+ if [[ $file =~ ^"${PLATFORM}"/libbpf-vmtest-rootfs-(.*)\.tar\.zst$ ]]; then
echo "${BASH_REMATCH[1]}"
fi
done
@@ -126,7 +136,7 @@ download_rootfs()
exit 1
fi
- download "${ARCH}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ download "${PLATFORM}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
zstd -d | sudo tar -C "$dir" -x
}
@@ -244,12 +254,17 @@ EOF
exit 1
fi
+ if [[ "${CROSS_COMPILE}" != "" ]]; then
+ QEMU_FLAGS=("${CROSS_FLAGS[@]}")
+ else
+ QEMU_FLAGS=("${HOST_FLAGS[@]}")
+ fi
+
${QEMU_BINARY} \
-nodefaults \
-display none \
-serial mon:stdio \
"${QEMU_FLAGS[@]}" \
- -enable-kvm \
-m 4G \
-drive file="${rootfs_img}",format=raw,index=1,media=disk,if=virtio,cache=none \
-kernel "${kernel_bzimage}" \
@@ -384,7 +399,8 @@ main()
fi
local kconfig_file="${OUTPUT_DIR}/latest.config"
- local make_command="make -j ${NUM_COMPILE_JOBS} KCONFIG_CONFIG=${kconfig_file}"
+ local make_command="make ARCH=${ARCH} CROSS_COMPILE=${CROSS_COMPILE} \
+ -j ${NUM_COMPILE_JOBS} KCONFIG_CONFIG=${kconfig_file}"
# Figure out where the kernel is being built.
# O takes precedence over KBUILD_OUTPUT.
--
2.34.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 1/5] selftests/bpf: Enable cross platform testing for local vmtest
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
The variable $ARCH in the current script is platform semantics, not
kernel semantics. Rename it to $PLATFORM so that we can easily use $ARCH
in cross-compilation. For now, Using PLATFORM= and CROSS_COMPILE=
options will enable cross platform testing:
PLATFORM=<platform> CROSS_COMPILE=<toolchain> vmtest.sh -- ./test_progs
Meanwhile, some descriptions have been corrected.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/vmtest.sh | 40 +++++++++++++++++++--------
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/bpf/vmtest.sh b/tools/testing/selftests/bpf/vmtest.sh
index 65d14f3bbe30..825149a905e5 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -4,28 +4,34 @@
set -u
set -e
-# This script currently only works for x86_64 and s390x, as
-# it is based on the VM image used by the BPF CI, which is
+# This script currently only works for the following platforms,
+# as it is based on the VM image used by the BPF CI, which is
# available only for these architectures.
-ARCH="$(uname -m)"
-case "${ARCH}" in
+PLATFORM="${PLATFORM:-$(uname -m)}"
+case "${PLATFORM}" in
s390x)
QEMU_BINARY=qemu-system-s390x
QEMU_CONSOLE="ttyS1"
- QEMU_FLAGS=(-smp 2)
+ HOST_FLAGS=(-smp 2 -enable-kvm)
+ CROSS_FLAGS=(-smp 2)
BZIMAGE="arch/s390/boot/vmlinux"
+ ARCH="s390"
;;
x86_64)
QEMU_BINARY=qemu-system-x86_64
QEMU_CONSOLE="ttyS0,115200"
- QEMU_FLAGS=(-cpu host -smp 8)
+ HOST_FLAGS=(-cpu host -enable-kvm -smp 8)
+ CROSS_FLAGS=(-smp 8)
BZIMAGE="arch/x86/boot/bzImage"
+ ARCH="x86"
;;
aarch64)
QEMU_BINARY=qemu-system-aarch64
QEMU_CONSOLE="ttyAMA0,115200"
- QEMU_FLAGS=(-M virt,gic-version=3 -cpu host -smp 8)
+ HOST_FLAGS=(-M virt,gic-version=3 -cpu host -enable-kvm -smp 8)
+ CROSS_FLAGS=(-M virt,gic-version=3 -cpu cortex-a76 -smp 8)
BZIMAGE="arch/arm64/boot/Image"
+ ARCH="arm64"
;;
*)
echo "Unsupported architecture"
@@ -38,7 +44,7 @@ ROOTFS_IMAGE="root.img"
OUTPUT_DIR="$HOME/.bpf_selftests"
KCONFIG_REL_PATHS=("tools/testing/selftests/bpf/config"
"tools/testing/selftests/bpf/config.vm"
- "tools/testing/selftests/bpf/config.${ARCH}")
+ "tools/testing/selftests/bpf/config.${PLATFORM}")
INDEX_URL="https://raw.githubusercontent.com/libbpf/ci/master/INDEX"
NUM_COMPILE_JOBS="$(nproc)"
LOG_FILE_BASE="$(date +"bpf_selftests.%Y-%m-%d_%H-%M-%S")"
@@ -58,6 +64,10 @@ tools/testing/selftests/bpf. e.g:
If no command is specified and a debug shell (-s) is not requested,
"${DEFAULT_COMMAND}" will be run by default.
+Using PLATFORM= and CROSS_COMPILE= options will enable cross platform testing:
+
+ PLATFORM=<platform> CROSS_COMPILE=<toolchain> $0 -- ./test_progs -t test_lsm
+
If you build your kernel using KBUILD_OUTPUT= or O= options, these
can be passed as environment variables to the script:
@@ -109,7 +119,7 @@ newest_rootfs_version()
{
{
for file in "${!URLS[@]}"; do
- if [[ $file =~ ^"${ARCH}"/libbpf-vmtest-rootfs-(.*)\.tar\.zst$ ]]; then
+ if [[ $file =~ ^"${PLATFORM}"/libbpf-vmtest-rootfs-(.*)\.tar\.zst$ ]]; then
echo "${BASH_REMATCH[1]}"
fi
done
@@ -126,7 +136,7 @@ download_rootfs()
exit 1
fi
- download "${ARCH}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ download "${PLATFORM}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
zstd -d | sudo tar -C "$dir" -x
}
@@ -244,12 +254,17 @@ EOF
exit 1
fi
+ if [[ "${CROSS_COMPILE}" != "" ]]; then
+ QEMU_FLAGS=("${CROSS_FLAGS[@]}")
+ else
+ QEMU_FLAGS=("${HOST_FLAGS[@]}")
+ fi
+
${QEMU_BINARY} \
-nodefaults \
-display none \
-serial mon:stdio \
"${QEMU_FLAGS[@]}" \
- -enable-kvm \
-m 4G \
-drive file="${rootfs_img}",format=raw,index=1,media=disk,if=virtio,cache=none \
-kernel "${kernel_bzimage}" \
@@ -384,7 +399,8 @@ main()
fi
local kconfig_file="${OUTPUT_DIR}/latest.config"
- local make_command="make -j ${NUM_COMPILE_JOBS} KCONFIG_CONFIG=${kconfig_file}"
+ local make_command="make ARCH=${ARCH} CROSS_COMPILE=${CROSS_COMPILE} \
+ -j ${NUM_COMPILE_JOBS} KCONFIG_CONFIG=${kconfig_file}"
# Figure out where the kernel is being built.
# O takes precedence over KBUILD_OUTPUT.
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-28 12:49 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
This patch relaxes the restrictions on the Zbb instructions. The hardware
is capable of recognizing the Zbb instructions independently, eliminating
the need for reliance on kernel compile configurations.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
arch/riscv/net/bpf_jit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index 5fc374ed98ea..bcf109b88df5 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
static inline bool rvzbb_enabled(void)
{
- return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
+ return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
}
enum {
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
This patch relaxes the restrictions on the Zbb instructions. The hardware
is capable of recognizing the Zbb instructions independently, eliminating
the need for reliance on kernel compile configurations.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
arch/riscv/net/bpf_jit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
index 5fc374ed98ea..bcf109b88df5 100644
--- a/arch/riscv/net/bpf_jit.h
+++ b/arch/riscv/net/bpf_jit.h
@@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
static inline bool rvzbb_enabled(void)
{
- return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) && riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
+ return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
}
enum {
--
2.34.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 3/5] selftests/bpf: Add config.riscv64
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-28 12:49 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
Add config.riscv64 for both BPF CI and local vmtest.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/config.riscv64 | 85 ++++++++++++++++++++++
1 file changed, 85 insertions(+)
create mode 100644 tools/testing/selftests/bpf/config.riscv64
diff --git a/tools/testing/selftests/bpf/config.riscv64 b/tools/testing/selftests/bpf/config.riscv64
new file mode 100644
index 000000000000..2f520cfdcb18
--- /dev/null
+++ b/tools/testing/selftests/bpf/config.riscv64
@@ -0,0 +1,85 @@
+CONFIG_AUDIT=y
+CONFIG_BLK_CGROUP=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BONDING=y
+CONFIG_BPF_JIT_ALWAYS_ON=y
+CONFIG_BPF_PRELOAD=y
+CONFIG_BPF_PRELOAD_UMD=y
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_HUGETLB=y
+CONFIG_CGROUP_NET_CLASSID=y
+CONFIG_CGROUP_PERF=y
+CONFIG_CGROUP_PIDS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CPUSETS=y
+CONFIG_DEBUG_ATOMIC_SLEEP=y
+CONFIG_DEBUG_FS=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_EXPERT=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_FRAME_POINTER=y
+CONFIG_HARDLOCKUP_DETECTOR=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_HUGETLBFS=y
+CONFIG_INET=y
+CONFIG_IPV6_SEG6_LWTUNNEL=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_JUMP_LABEL=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KPROBES=y
+CONFIG_MEMCG=y
+CONFIG_NAMESPACES=y
+CONFIG_NET=y
+CONFIG_NETDEVICES=y
+CONFIG_NETFILTER_XT_MATCH_BPF=y
+CONFIG_NET_ACT_BPF=y
+CONFIG_NET_L3_MASTER_DEV=y
+CONFIG_NET_VRF=y
+CONFIG_NONPORTABLE=y
+CONFIG_NO_HZ_IDLE=y
+CONFIG_NR_CPUS=256
+CONFIG_PACKET=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_PCI=y
+CONFIG_PCI_HOST_GENERIC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_PRINTK_TIME=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROFILING=y
+CONFIG_RCU_CPU_STALL_TIMEOUT=60
+CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_RISCV_ISA_C=y
+CONFIG_RISCV_PMU=y
+CONFIG_RISCV_PMU_SBI=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_SECURITY_NETWORK=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SMP=y
+CONFIG_SOC_VIRT=y
+CONFIG_SYSVIPC=y
+CONFIG_TCP_CONG_ADVANCED=y
+CONFIG_TLS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_TUN=y
+CONFIG_UNIX=y
+CONFIG_UPROBES=y
+CONFIG_USER_NS=y
+CONFIG_VETH=y
+CONFIG_VLAN_8021Q=y
+CONFIG_VSOCKETS_LOOPBACK=y
+CONFIG_XFRM_USER=y
--
2.34.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 3/5] selftests/bpf: Add config.riscv64
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
Add config.riscv64 for both BPF CI and local vmtest.
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/config.riscv64 | 85 ++++++++++++++++++++++
1 file changed, 85 insertions(+)
create mode 100644 tools/testing/selftests/bpf/config.riscv64
diff --git a/tools/testing/selftests/bpf/config.riscv64 b/tools/testing/selftests/bpf/config.riscv64
new file mode 100644
index 000000000000..2f520cfdcb18
--- /dev/null
+++ b/tools/testing/selftests/bpf/config.riscv64
@@ -0,0 +1,85 @@
+CONFIG_AUDIT=y
+CONFIG_BLK_CGROUP=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BONDING=y
+CONFIG_BPF_JIT_ALWAYS_ON=y
+CONFIG_BPF_PRELOAD=y
+CONFIG_BPF_PRELOAD_UMD=y
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_HUGETLB=y
+CONFIG_CGROUP_NET_CLASSID=y
+CONFIG_CGROUP_PERF=y
+CONFIG_CGROUP_PIDS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CPUSETS=y
+CONFIG_DEBUG_ATOMIC_SLEEP=y
+CONFIG_DEBUG_FS=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_EXPERT=y
+CONFIG_EXT4_FS=y
+CONFIG_EXT4_FS_POSIX_ACL=y
+CONFIG_EXT4_FS_SECURITY=y
+CONFIG_FRAME_POINTER=y
+CONFIG_HARDLOCKUP_DETECTOR=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_HUGETLBFS=y
+CONFIG_INET=y
+CONFIG_IPV6_SEG6_LWTUNNEL=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_JUMP_LABEL=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KPROBES=y
+CONFIG_MEMCG=y
+CONFIG_NAMESPACES=y
+CONFIG_NET=y
+CONFIG_NETDEVICES=y
+CONFIG_NETFILTER_XT_MATCH_BPF=y
+CONFIG_NET_ACT_BPF=y
+CONFIG_NET_L3_MASTER_DEV=y
+CONFIG_NET_VRF=y
+CONFIG_NONPORTABLE=y
+CONFIG_NO_HZ_IDLE=y
+CONFIG_NR_CPUS=256
+CONFIG_PACKET=y
+CONFIG_PANIC_ON_OOPS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_PCI=y
+CONFIG_PCI_HOST_GENERIC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_PRINTK_TIME=y
+CONFIG_PROC_KCORE=y
+CONFIG_PROFILING=y
+CONFIG_RCU_CPU_STALL_TIMEOUT=60
+CONFIG_RISCV_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_RISCV_ISA_C=y
+CONFIG_RISCV_PMU=y
+CONFIG_RISCV_PMU_SBI=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_SECURITY_NETWORK=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SMP=y
+CONFIG_SOC_VIRT=y
+CONFIG_SYSVIPC=y
+CONFIG_TCP_CONG_ADVANCED=y
+CONFIG_TLS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_TUN=y
+CONFIG_UNIX=y
+CONFIG_UPROBES=y
+CONFIG_USER_NS=y
+CONFIG_VETH=y
+CONFIG_VLAN_8021Q=y
+CONFIG_VSOCKETS_LOOPBACK=y
+CONFIG_XFRM_USER=y
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 4/5] selftests/bpf: Add DENYLIST.riscv64
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-28 12:49 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
This patch adds DENYLIST.riscv64 file for riscv64. It will help BPF CI
and local vmtest to mask failing and unsupported test cases.
We can use the following command to use deny list in local vmtest as
previously mentioned by Manu.
tools/testing/selftests/bpf/vmtest.sh -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/DENYLIST.riscv64 | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 tools/testing/selftests/bpf/DENYLIST.riscv64
diff --git a/tools/testing/selftests/bpf/DENYLIST.riscv64 b/tools/testing/selftests/bpf/DENYLIST.riscv64
new file mode 100644
index 000000000000..ebb4cc44c549
--- /dev/null
+++ b/tools/testing/selftests/bpf/DENYLIST.riscv64
@@ -0,0 +1,5 @@
+# riscv64 deny list for BPF CI and local vmtest
+exceptions # JIT does not support exceptions
+fentry_test/fentry_many_args # JIT does not support 12 args of bpf trampoline
+fexit_test/fexit_many_args # JIT does not support 12 args of bpf trampoline
+tailcalls/tailcall_bpf2bpf* # JIT does not support mixing bpf2bpf and tailcalls
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 4/5] selftests/bpf: Add DENYLIST.riscv64
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
This patch adds DENYLIST.riscv64 file for riscv64. It will help BPF CI
and local vmtest to mask failing and unsupported test cases.
We can use the following command to use deny list in local vmtest as
previously mentioned by Manu.
tools/testing/selftests/bpf/vmtest.sh -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/DENYLIST.riscv64 | 5 +++++
1 file changed, 5 insertions(+)
create mode 100644 tools/testing/selftests/bpf/DENYLIST.riscv64
diff --git a/tools/testing/selftests/bpf/DENYLIST.riscv64 b/tools/testing/selftests/bpf/DENYLIST.riscv64
new file mode 100644
index 000000000000..ebb4cc44c549
--- /dev/null
+++ b/tools/testing/selftests/bpf/DENYLIST.riscv64
@@ -0,0 +1,5 @@
+# riscv64 deny list for BPF CI and local vmtest
+exceptions # JIT does not support exceptions
+fentry_test/fentry_many_args # JIT does not support 12 args of bpf trampoline
+fexit_test/fexit_many_args # JIT does not support 12 args of bpf trampoline
+tailcalls/tailcall_bpf2bpf* # JIT does not support mixing bpf2bpf and tailcalls
--
2.34.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 5/5] selftests/bpf: Add riscv64 configurations to local vmtest
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-28 12:49 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
Add riscv64 configurations to local vmtest.
We can now perform cross platform testing for riscv64 bpf using the
following command:
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/vmtest.sh | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/bpf/vmtest.sh b/tools/testing/selftests/bpf/vmtest.sh
index 825149a905e5..f6889de9b498 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -33,6 +33,14 @@ aarch64)
BZIMAGE="arch/arm64/boot/Image"
ARCH="arm64"
;;
+riscv64)
+ QEMU_BINARY=qemu-system-riscv64
+ QEMU_CONSOLE="ttyS0,115200"
+ HOST_FLAGS=(-M virt -cpu host -enable-kvm -smp 8)
+ CROSS_FLAGS=(-M virt -cpu rv64,sscofpmf=true -smp 8)
+ BZIMAGE="arch/riscv/boot/Image"
+ ARCH="riscv"
+ ;;
*)
echo "Unsupported architecture"
exit 1
--
2.34.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH bpf-next 5/5] selftests/bpf: Add riscv64 configurations to local vmtest
@ 2024-03-28 12:49 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-28 12:49 UTC (permalink / raw)
To: bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui,
Pu Lehui
From: Pu Lehui <pulehui@huawei.com>
Add riscv64 configurations to local vmtest.
We can now perform cross platform testing for riscv64 bpf using the
following command:
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
tools/testing/selftests/bpf/vmtest.sh | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/bpf/vmtest.sh b/tools/testing/selftests/bpf/vmtest.sh
index 825149a905e5..f6889de9b498 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -33,6 +33,14 @@ aarch64)
BZIMAGE="arch/arm64/boot/Image"
ARCH="arm64"
;;
+riscv64)
+ QEMU_BINARY=qemu-system-riscv64
+ QEMU_CONSOLE="ttyS0,115200"
+ HOST_FLAGS=(-M virt -cpu host -enable-kvm -smp 8)
+ CROSS_FLAGS=(-M virt -cpu rv64,sscofpmf=true -smp 8)
+ BZIMAGE="arch/riscv/boot/Image"
+ ARCH="riscv"
+ ;;
*)
echo "Unsupported architecture"
exit 1
--
2.34.1
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-28 19:34 ` Stefan O'Rear
-1 siblings, 0 replies; 60+ messages in thread
From: Stefan O'Rear @ 2024-03-28 19:34 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
> From: Pu Lehui <pulehui@huawei.com>
>
> This patch relaxes the restrictions on the Zbb instructions. The hardware
> is capable of recognizing the Zbb instructions independently, eliminating
> the need for reliance on kernel compile configurations.
This doesn't make sense to me.
RISCV_ISA_ZBB is defined as:
Adds support to dynamically detect the presence of the ZBB
extension (basic bit manipulation) and enable its usage.
In other words, RISCV_ISA_ZBB=n should disable everything that attempts
to detect Zbb at runtime. It is mostly relevant for code size reduction,
which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
checks can be constant-folded.
If BPF needs to become an exception (why?), this should be mentioned in
Kconfig.
-s
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
> arch/riscv/net/bpf_jit.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> index 5fc374ed98ea..bcf109b88df5 100644
> --- a/arch/riscv/net/bpf_jit.h
> +++ b/arch/riscv/net/bpf_jit.h
> @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
>
> static inline bool rvzbb_enabled(void)
> {
> - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) &&
> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> }
>
> enum {
> --
> 2.34.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-28 19:34 ` Stefan O'Rear
0 siblings, 0 replies; 60+ messages in thread
From: Stefan O'Rear @ 2024-03-28 19:34 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
> From: Pu Lehui <pulehui@huawei.com>
>
> This patch relaxes the restrictions on the Zbb instructions. The hardware
> is capable of recognizing the Zbb instructions independently, eliminating
> the need for reliance on kernel compile configurations.
This doesn't make sense to me.
RISCV_ISA_ZBB is defined as:
Adds support to dynamically detect the presence of the ZBB
extension (basic bit manipulation) and enable its usage.
In other words, RISCV_ISA_ZBB=n should disable everything that attempts
to detect Zbb at runtime. It is mostly relevant for code size reduction,
which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
checks can be constant-folded.
If BPF needs to become an exception (why?), this should be mentioned in
Kconfig.
-s
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
> ---
> arch/riscv/net/bpf_jit.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> index 5fc374ed98ea..bcf109b88df5 100644
> --- a/arch/riscv/net/bpf_jit.h
> +++ b/arch/riscv/net/bpf_jit.h
> @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
>
> static inline bool rvzbb_enabled(void)
> {
> - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) &&
> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> }
>
> enum {
> --
> 2.34.1
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-28 19:34 ` Stefan O'Rear
@ 2024-03-28 22:07 ` Conor Dooley
-1 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-03-28 22:07 UTC (permalink / raw)
To: Stefan O'Rear
Cc: Pu Lehui, bpf, linux-riscv, netdev, Björn Töpel,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1.1: Type: text/plain, Size: 2946 bytes --]
On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
> > From: Pu Lehui <pulehui@huawei.com>
> >
> > This patch relaxes the restrictions on the Zbb instructions. The hardware
> > is capable of recognizing the Zbb instructions independently, eliminating
> > the need for reliance on kernel compile configurations.
>
> This doesn't make sense to me.
It doesn't make sense to me either. Of course the hardware's capability
to understand an instruction is independent of whether or not a
toolchain is capable of actually emitting the instruction.
> RISCV_ISA_ZBB is defined as:
>
> Adds support to dynamically detect the presence of the ZBB
> extension (basic bit manipulation) and enable its usage.
>
> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
> to detect Zbb at runtime. It is mostly relevant for code size reduction,
> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
> checks can be constant-folded.
>
> If BPF needs to become an exception (why?), this should be mentioned in
> Kconfig.
And in the commit message. On one hand I think this could be a reasonable
thing to do in bpf as it is acting as a jit here, and doesn't actually
need the alternatives that we are using elsewhere to enable the
optimisations nor the compiler support. On the other the intention of
that kconfig option is to control optimisations like rvzbb_enabled()
gates, so this is gonna need a proper justification as to
As I said on IRC to you earlier, I think the Kconfig options here are in
need of a bit of a spring cleaning - they should be modified to explain
their individual purposes, be that enabling optimisations in the kernel
or being required for userspace. I'll try to send a patch for that if
I remember tomorrow.
Thanks,
Conor.
> > Signed-off-by: Pu Lehui <pulehui@huawei.com>
> > ---
> > arch/riscv/net/bpf_jit.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> > index 5fc374ed98ea..bcf109b88df5 100644
> > --- a/arch/riscv/net/bpf_jit.h
> > +++ b/arch/riscv/net/bpf_jit.h
> > @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
> >
> > static inline bool rvzbb_enabled(void)
> > {
> > - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) &&
> > riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> > + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> > }
> >
> > enum {
> > --
> > 2.34.1
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-28 22:07 ` Conor Dooley
0 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-03-28 22:07 UTC (permalink / raw)
To: Stefan O'Rear
Cc: Pu Lehui, bpf, linux-riscv, netdev, Björn Töpel,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]
On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
> > From: Pu Lehui <pulehui@huawei.com>
> >
> > This patch relaxes the restrictions on the Zbb instructions. The hardware
> > is capable of recognizing the Zbb instructions independently, eliminating
> > the need for reliance on kernel compile configurations.
>
> This doesn't make sense to me.
It doesn't make sense to me either. Of course the hardware's capability
to understand an instruction is independent of whether or not a
toolchain is capable of actually emitting the instruction.
> RISCV_ISA_ZBB is defined as:
>
> Adds support to dynamically detect the presence of the ZBB
> extension (basic bit manipulation) and enable its usage.
>
> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
> to detect Zbb at runtime. It is mostly relevant for code size reduction,
> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
> checks can be constant-folded.
>
> If BPF needs to become an exception (why?), this should be mentioned in
> Kconfig.
And in the commit message. On one hand I think this could be a reasonable
thing to do in bpf as it is acting as a jit here, and doesn't actually
need the alternatives that we are using elsewhere to enable the
optimisations nor the compiler support. On the other the intention of
that kconfig option is to control optimisations like rvzbb_enabled()
gates, so this is gonna need a proper justification as to
As I said on IRC to you earlier, I think the Kconfig options here are in
need of a bit of a spring cleaning - they should be modified to explain
their individual purposes, be that enabling optimisations in the kernel
or being required for userspace. I'll try to send a patch for that if
I remember tomorrow.
Thanks,
Conor.
> > Signed-off-by: Pu Lehui <pulehui@huawei.com>
> > ---
> > arch/riscv/net/bpf_jit.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
> > index 5fc374ed98ea..bcf109b88df5 100644
> > --- a/arch/riscv/net/bpf_jit.h
> > +++ b/arch/riscv/net/bpf_jit.h
> > @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
> >
> > static inline bool rvzbb_enabled(void)
> > {
> > - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) &&
> > riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> > + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
> > }
> >
> > enum {
> > --
> > 2.34.1
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
2024-03-28 12:49 ` Pu Lehui
@ 2024-03-29 9:08 ` Eduard Zingerman
-1 siblings, 0 replies; 60+ messages in thread
From: Eduard Zingerman @ 2024-03-29 9:08 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On Thu, 2024-03-28 at 12:49 +0000, Pu Lehui wrote:
> Patch 1 is to enable cross platform testing for local vmtest. The
> remaining patch adds local vmtest support for riscv64. It relies on
> commit [0] [1] for better regression.
>
> We can now perform cross platform testing for riscv64 bpf using the
> following command:
>
> PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
> tools/testing/selftests/bpf/vmtest.sh -- \
> ./test_progs -d \
> \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
> | cut -d'#' -f1 \
> | sed -e 's/^[[:space:]]*//' \
> -e 's/[[:space:]]*$//' \
> | tr -s '\n' ','\
> )\"
>
> The test platform is x86_64 architecture, and the versions of relevant
> components are as follows:
> QEMU: 8.2.0
> CLANG: 17.0.6 (align to BPF CI)
> OpenSBI: 1.3.1 (default by QEMU)
> ROOTFS: ubuntu jammy (generated by [2])
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493 [0]
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=443574b033876c85 [1]
> Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [2]
Hello,
I wanted to do a test run for this patch-set but did not figure out
how to build rootfs for riscv64 system.
I modified mkrootfs_debian.sh as below, but build command fails:
$ ./rootfs/mkrootfs_debian.sh -d jammy -a riscv64 -m http://de.archive.ubuntu.com/ubuntu
...
E: Couldn't download http://de.archive.ubuntu.com/ubuntu/dists/jammy/main/binary-riscv64/Packages
Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
Could you please provide some instructions on how to prepare rootfs?
Thanks,
Eduard
--
diff --git a/rootfs/mkrootfs_debian.sh b/rootfs/mkrootfs_debian.sh
index dfe957e..1d5b769 100755
--- a/rootfs/mkrootfs_debian.sh
+++ b/rootfs/mkrootfs_debian.sh
@@ -16,6 +16,7 @@ CPUTABLE="${CPUTABLE:-/usr/share/dpkg/cputable}"
deb_arch=$(dpkg --print-architecture)
distro="bullseye"
+mirror=""
function usage() {
echo "Usage: $0 [-a | --arch architecture] [-h | --help]
@@ -25,6 +26,7 @@ By default build an image for the architecture of the host running the script.
-a | --arch: architecture to build the image for. Default (${deb_arch})
-d | --distro: distribution to build. Default (${distro})
+ -m | --mirror: mirror for distribution to build. Default (${mirror})
"
}
@@ -44,7 +46,7 @@ function qemu_static() {
# Given a Debian architecture find the location of the matching
# qemu-${gnu_arch}-static binary.
gnu_arch=$(debian_to_gnu "${1}")
- echo "qemu-${gnu_arch}-static"
+ echo "qemu-${gnu_arch}"
}
function check_requirements() {
@@ -95,7 +97,7 @@ function check_requirements() {
fi
}
-TEMP=$(getopt -l "arch:,distro:,help" -o "a:d:h" -- "$@")
+TEMP=$(getopt -l "arch:,distro:,mirror:,help" -o "a:d:m:h" -- "$@")
if [ $? -ne 0 ]; then
usage
fi
@@ -113,6 +115,10 @@ while true; do
distro="$2"
shift 2
;;
+ --mirror | -m)
+ mirror="$2"
+ shift 2
+ ;;
--help | -h)
usage
exit
@@ -162,7 +168,8 @@ debootstrap --include="$packages" \
--arch="${deb_arch}" \
"$@" \
"${distro}" \
- "$root"
+ "$root" \
+ "${mirror}"
qemu=$(which $(qemu_static ${deb_arch}))
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-29 9:08 ` Eduard Zingerman
0 siblings, 0 replies; 60+ messages in thread
From: Eduard Zingerman @ 2024-03-29 9:08 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On Thu, 2024-03-28 at 12:49 +0000, Pu Lehui wrote:
> Patch 1 is to enable cross platform testing for local vmtest. The
> remaining patch adds local vmtest support for riscv64. It relies on
> commit [0] [1] for better regression.
>
> We can now perform cross platform testing for riscv64 bpf using the
> following command:
>
> PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
> tools/testing/selftests/bpf/vmtest.sh -- \
> ./test_progs -d \
> \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
> | cut -d'#' -f1 \
> | sed -e 's/^[[:space:]]*//' \
> -e 's/[[:space:]]*$//' \
> | tr -s '\n' ','\
> )\"
>
> The test platform is x86_64 architecture, and the versions of relevant
> components are as follows:
> QEMU: 8.2.0
> CLANG: 17.0.6 (align to BPF CI)
> OpenSBI: 1.3.1 (default by QEMU)
> ROOTFS: ubuntu jammy (generated by [2])
>
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493 [0]
> Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=443574b033876c85 [1]
> Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [2]
Hello,
I wanted to do a test run for this patch-set but did not figure out
how to build rootfs for riscv64 system.
I modified mkrootfs_debian.sh as below, but build command fails:
$ ./rootfs/mkrootfs_debian.sh -d jammy -a riscv64 -m http://de.archive.ubuntu.com/ubuntu
...
E: Couldn't download http://de.archive.ubuntu.com/ubuntu/dists/jammy/main/binary-riscv64/Packages
Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
Could you please provide some instructions on how to prepare rootfs?
Thanks,
Eduard
--
diff --git a/rootfs/mkrootfs_debian.sh b/rootfs/mkrootfs_debian.sh
index dfe957e..1d5b769 100755
--- a/rootfs/mkrootfs_debian.sh
+++ b/rootfs/mkrootfs_debian.sh
@@ -16,6 +16,7 @@ CPUTABLE="${CPUTABLE:-/usr/share/dpkg/cputable}"
deb_arch=$(dpkg --print-architecture)
distro="bullseye"
+mirror=""
function usage() {
echo "Usage: $0 [-a | --arch architecture] [-h | --help]
@@ -25,6 +26,7 @@ By default build an image for the architecture of the host running the script.
-a | --arch: architecture to build the image for. Default (${deb_arch})
-d | --distro: distribution to build. Default (${distro})
+ -m | --mirror: mirror for distribution to build. Default (${mirror})
"
}
@@ -44,7 +46,7 @@ function qemu_static() {
# Given a Debian architecture find the location of the matching
# qemu-${gnu_arch}-static binary.
gnu_arch=$(debian_to_gnu "${1}")
- echo "qemu-${gnu_arch}-static"
+ echo "qemu-${gnu_arch}"
}
function check_requirements() {
@@ -95,7 +97,7 @@ function check_requirements() {
fi
}
-TEMP=$(getopt -l "arch:,distro:,help" -o "a:d:h" -- "$@")
+TEMP=$(getopt -l "arch:,distro:,mirror:,help" -o "a:d:m:h" -- "$@")
if [ $? -ne 0 ]; then
usage
fi
@@ -113,6 +115,10 @@ while true; do
distro="$2"
shift 2
;;
+ --mirror | -m)
+ mirror="$2"
+ shift 2
+ ;;
--help | -h)
usage
exit
@@ -162,7 +168,8 @@ debootstrap --include="$packages" \
--arch="${deb_arch}" \
"$@" \
"${distro}" \
- "$root"
+ "$root" \
+ "${mirror}"
qemu=$(which $(qemu_static ${deb_arch}))
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-28 22:07 ` Conor Dooley
@ 2024-03-29 10:05 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-29 10:05 UTC (permalink / raw)
To: Stefan O'Rear, Conor Dooley
Cc: bpf, linux-riscv, netdev, Björn Töpel,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/29 6:07, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>>> From: Pu Lehui <pulehui@huawei.com>
>>>
>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>>> is capable of recognizing the Zbb instructions independently, eliminating
>>> the need for reliance on kernel compile configurations.
>>
>> This doesn't make sense to me.
>
> It doesn't make sense to me either. Of course the hardware's capability
> to understand an instruction is independent of whether or not a
> toolchain is capable of actually emitting the instruction.
>
>> RISCV_ISA_ZBB is defined as:
>>
>> Adds support to dynamically detect the presence of the ZBB
>> extension (basic bit manipulation) and enable its usage.
>>
>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>> checks can be constant-folded.
Thanks for review. My initial thought was the same as yours, but after
discussions [0] and test verifications, the hardware can indeed
recognize the zbb instruction even if the kernel has not enabled
CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
Link:
https://lore.kernel.org/bpf/20240129-d06c79a17a5091b3403fc5b6@orel/ [0]
>>
>> If BPF needs to become an exception (why?), this should be mentioned in
>> Kconfig.
>
> And in the commit message. On one hand I think this could be a reasonable
> thing to do in bpf as it is acting as a jit here, and doesn't actually
> need the alternatives that we are using elsewhere to enable the
> optimisations nor the compiler support. On the other the intention of
> that kconfig option is to control optimisations like rvzbb_enabled()
> gates, so this is gonna need a proper justification as to
>
> As I said on IRC to you earlier, I think the Kconfig options here are in
> need of a bit of a spring cleaning - they should be modified to explain
> their individual purposes, be that enabling optimisations in the kernel
> or being required for userspace. I'll try to send a patch for that if
> I remember tomorrow.
>
> Thanks,
> Conor.
>
>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>> ---
>>> arch/riscv/net/bpf_jit.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>> index 5fc374ed98ea..bcf109b88df5 100644
>>> --- a/arch/riscv/net/bpf_jit.h
>>> +++ b/arch/riscv/net/bpf_jit.h
>>> @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
>>>
>>> static inline bool rvzbb_enabled(void)
>>> {
>>> - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) &&
>>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>> + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>> }
>>>
>>> enum {
>>> --
>>> 2.34.1
>>>
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-29 10:05 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-29 10:05 UTC (permalink / raw)
To: Stefan O'Rear, Conor Dooley
Cc: bpf, linux-riscv, netdev, Björn Töpel,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/29 6:07, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>>> From: Pu Lehui <pulehui@huawei.com>
>>>
>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>>> is capable of recognizing the Zbb instructions independently, eliminating
>>> the need for reliance on kernel compile configurations.
>>
>> This doesn't make sense to me.
>
> It doesn't make sense to me either. Of course the hardware's capability
> to understand an instruction is independent of whether or not a
> toolchain is capable of actually emitting the instruction.
>
>> RISCV_ISA_ZBB is defined as:
>>
>> Adds support to dynamically detect the presence of the ZBB
>> extension (basic bit manipulation) and enable its usage.
>>
>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>> checks can be constant-folded.
Thanks for review. My initial thought was the same as yours, but after
discussions [0] and test verifications, the hardware can indeed
recognize the zbb instruction even if the kernel has not enabled
CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
Link:
https://lore.kernel.org/bpf/20240129-d06c79a17a5091b3403fc5b6@orel/ [0]
>>
>> If BPF needs to become an exception (why?), this should be mentioned in
>> Kconfig.
>
> And in the commit message. On one hand I think this could be a reasonable
> thing to do in bpf as it is acting as a jit here, and doesn't actually
> need the alternatives that we are using elsewhere to enable the
> optimisations nor the compiler support. On the other the intention of
> that kconfig option is to control optimisations like rvzbb_enabled()
> gates, so this is gonna need a proper justification as to
>
> As I said on IRC to you earlier, I think the Kconfig options here are in
> need of a bit of a spring cleaning - they should be modified to explain
> their individual purposes, be that enabling optimisations in the kernel
> or being required for userspace. I'll try to send a patch for that if
> I remember tomorrow.
>
> Thanks,
> Conor.
>
>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>> ---
>>> arch/riscv/net/bpf_jit.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/riscv/net/bpf_jit.h b/arch/riscv/net/bpf_jit.h
>>> index 5fc374ed98ea..bcf109b88df5 100644
>>> --- a/arch/riscv/net/bpf_jit.h
>>> +++ b/arch/riscv/net/bpf_jit.h
>>> @@ -20,7 +20,7 @@ static inline bool rvc_enabled(void)
>>>
>>> static inline bool rvzbb_enabled(void)
>>> {
>>> - return IS_ENABLED(CONFIG_RISCV_ISA_ZBB) &&
>>> riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>> + return riscv_has_extension_likely(RISCV_ISA_EXT_ZBB);
>>> }
>>>
>>> enum {
>>> --
>>> 2.34.1
>>>
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
2024-03-29 9:08 ` Eduard Zingerman
@ 2024-03-29 10:10 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-29 10:10 UTC (permalink / raw)
To: Eduard Zingerman, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/29 17:08, Eduard Zingerman wrote:
> On Thu, 2024-03-28 at 12:49 +0000, Pu Lehui wrote:
>> Patch 1 is to enable cross platform testing for local vmtest. The
>> remaining patch adds local vmtest support for riscv64. It relies on
>> commit [0] [1] for better regression.
>>
>> We can now perform cross platform testing for riscv64 bpf using the
>> following command:
>>
>> PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
>> tools/testing/selftests/bpf/vmtest.sh -- \
>> ./test_progs -d \
>> \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
>> | cut -d'#' -f1 \
>> | sed -e 's/^[[:space:]]*//' \
>> -e 's/[[:space:]]*$//' \
>> | tr -s '\n' ','\
>> )\"
>>
>> The test platform is x86_64 architecture, and the versions of relevant
>> components are as follows:
>> QEMU: 8.2.0
>> CLANG: 17.0.6 (align to BPF CI)
>> OpenSBI: 1.3.1 (default by QEMU)
>> ROOTFS: ubuntu jammy (generated by [2])
>>
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493 [0]
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=443574b033876c85 [1]
>> Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [2]
>
> Hello,
>
> I wanted to do a test run for this patch-set but did not figure out
> how to build rootfs for riscv64 system.
>
> I modified mkrootfs_debian.sh as below, but build command fails:
>
> $ ./rootfs/mkrootfs_debian.sh -d jammy -a riscv64 -m http://de.archive.ubuntu.com/ubuntu
> ...
> E: Couldn't download http://de.archive.ubuntu.com/ubuntu/dists/jammy/main/binary-riscv64/Packages
>
> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
> Could you please provide some instructions on how to prepare rootfs?
Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
http://de.ports.ubuntu.com/.
>
> Thanks,
> Eduard
>
> --
>
> diff --git a/rootfs/mkrootfs_debian.sh b/rootfs/mkrootfs_debian.sh
> index dfe957e..1d5b769 100755
> --- a/rootfs/mkrootfs_debian.sh
> +++ b/rootfs/mkrootfs_debian.sh
> @@ -16,6 +16,7 @@ CPUTABLE="${CPUTABLE:-/usr/share/dpkg/cputable}"
>
> deb_arch=$(dpkg --print-architecture)
> distro="bullseye"
> +mirror=""
>
> function usage() {
> echo "Usage: $0 [-a | --arch architecture] [-h | --help]
> @@ -25,6 +26,7 @@ By default build an image for the architecture of the host running the script.
>
> -a | --arch: architecture to build the image for. Default (${deb_arch})
> -d | --distro: distribution to build. Default (${distro})
> + -m | --mirror: mirror for distribution to build. Default (${mirror})
> "
> }
>
> @@ -44,7 +46,7 @@ function qemu_static() {
> # Given a Debian architecture find the location of the matching
> # qemu-${gnu_arch}-static binary.
> gnu_arch=$(debian_to_gnu "${1}")
> - echo "qemu-${gnu_arch}-static"
> + echo "qemu-${gnu_arch}"
> }
>
> function check_requirements() {
> @@ -95,7 +97,7 @@ function check_requirements() {
> fi
> }
>
> -TEMP=$(getopt -l "arch:,distro:,help" -o "a:d:h" -- "$@")
> +TEMP=$(getopt -l "arch:,distro:,mirror:,help" -o "a:d:m:h" -- "$@")
> if [ $? -ne 0 ]; then
> usage
> fi
> @@ -113,6 +115,10 @@ while true; do
> distro="$2"
> shift 2
> ;;
> + --mirror | -m)
> + mirror="$2"
> + shift 2
> + ;;
> --help | -h)
> usage
> exit
> @@ -162,7 +168,8 @@ debootstrap --include="$packages" \
> --arch="${deb_arch}" \
> "$@" \
> "${distro}" \
> - "$root"
> + "$root" \
> + "${mirror}"
>
> qemu=$(which $(qemu_static ${deb_arch}))
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-29 10:10 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-29 10:10 UTC (permalink / raw)
To: Eduard Zingerman, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/29 17:08, Eduard Zingerman wrote:
> On Thu, 2024-03-28 at 12:49 +0000, Pu Lehui wrote:
>> Patch 1 is to enable cross platform testing for local vmtest. The
>> remaining patch adds local vmtest support for riscv64. It relies on
>> commit [0] [1] for better regression.
>>
>> We can now perform cross platform testing for riscv64 bpf using the
>> following command:
>>
>> PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
>> tools/testing/selftests/bpf/vmtest.sh -- \
>> ./test_progs -d \
>> \"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
>> | cut -d'#' -f1 \
>> | sed -e 's/^[[:space:]]*//' \
>> -e 's/[[:space:]]*$//' \
>> | tr -s '\n' ','\
>> )\"
>>
>> The test platform is x86_64 architecture, and the versions of relevant
>> components are as follows:
>> QEMU: 8.2.0
>> CLANG: 17.0.6 (align to BPF CI)
>> OpenSBI: 1.3.1 (default by QEMU)
>> ROOTFS: ubuntu jammy (generated by [2])
>>
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493 [0]
>> Link: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=443574b033876c85 [1]
>> Link: https://github.com/libbpf/ci/blob/main/rootfs/mkrootfs_debian.sh [2]
>
> Hello,
>
> I wanted to do a test run for this patch-set but did not figure out
> how to build rootfs for riscv64 system.
>
> I modified mkrootfs_debian.sh as below, but build command fails:
>
> $ ./rootfs/mkrootfs_debian.sh -d jammy -a riscv64 -m http://de.archive.ubuntu.com/ubuntu
> ...
> E: Couldn't download http://de.archive.ubuntu.com/ubuntu/dists/jammy/main/binary-riscv64/Packages
>
> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
> Could you please provide some instructions on how to prepare rootfs?
Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
http://de.ports.ubuntu.com/.
>
> Thanks,
> Eduard
>
> --
>
> diff --git a/rootfs/mkrootfs_debian.sh b/rootfs/mkrootfs_debian.sh
> index dfe957e..1d5b769 100755
> --- a/rootfs/mkrootfs_debian.sh
> +++ b/rootfs/mkrootfs_debian.sh
> @@ -16,6 +16,7 @@ CPUTABLE="${CPUTABLE:-/usr/share/dpkg/cputable}"
>
> deb_arch=$(dpkg --print-architecture)
> distro="bullseye"
> +mirror=""
>
> function usage() {
> echo "Usage: $0 [-a | --arch architecture] [-h | --help]
> @@ -25,6 +26,7 @@ By default build an image for the architecture of the host running the script.
>
> -a | --arch: architecture to build the image for. Default (${deb_arch})
> -d | --distro: distribution to build. Default (${distro})
> + -m | --mirror: mirror for distribution to build. Default (${mirror})
> "
> }
>
> @@ -44,7 +46,7 @@ function qemu_static() {
> # Given a Debian architecture find the location of the matching
> # qemu-${gnu_arch}-static binary.
> gnu_arch=$(debian_to_gnu "${1}")
> - echo "qemu-${gnu_arch}-static"
> + echo "qemu-${gnu_arch}"
> }
>
> function check_requirements() {
> @@ -95,7 +97,7 @@ function check_requirements() {
> fi
> }
>
> -TEMP=$(getopt -l "arch:,distro:,help" -o "a:d:h" -- "$@")
> +TEMP=$(getopt -l "arch:,distro:,mirror:,help" -o "a:d:m:h" -- "$@")
> if [ $? -ne 0 ]; then
> usage
> fi
> @@ -113,6 +115,10 @@ while true; do
> distro="$2"
> shift 2
> ;;
> + --mirror | -m)
> + mirror="$2"
> + shift 2
> + ;;
> --help | -h)
> usage
> exit
> @@ -162,7 +168,8 @@ debootstrap --include="$packages" \
> --arch="${deb_arch}" \
> "$@" \
> "${distro}" \
> - "$root"
> + "$root" \
> + "${mirror}"
>
> qemu=$(which $(qemu_static ${deb_arch}))
>
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-28 22:07 ` Conor Dooley
@ 2024-03-29 11:23 ` Conor Dooley
-1 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-03-29 11:23 UTC (permalink / raw)
To: Conor Dooley
Cc: Stefan O'Rear, Pu Lehui, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1.1: Type: text/plain, Size: 4727 bytes --]
On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
> As I said on IRC to you earlier, I think the Kconfig options here are in
> need of a bit of a spring cleaning - they should be modified to explain
> their individual purposes, be that enabling optimisations in the kernel
> or being required for userspace. I'll try to send a patch for that if
> I remember tomorrow.
Something like this:
-- >8 --
commit 5125504beaedd669b082bf74b02003a77360670f
Author: Conor Dooley <conor.dooley@microchip.com>
Date: Fri Mar 29 11:13:22 2024 +0000
RISC-V: clarify what some RISCV_ISA* config options do
During some discussion on IRC yesterday and on Pu's bpf patch [1]
I noticed that these RISCV_ISA* Kconfig options are not really clear
about their implications. Many of these options have no impact on what
userspace is allowed to do, for example an application can use Zbb
regardless of whether or not the kernel does. Change the help text to
try and clarify whether or not an option affects just the kernel, or
also userspace. None of these options actually control whether or not an
extension is detected dynamically as that's done regardless of Kconfig
options, so drop any text that implies the option is required for
dynamic detection, rewording them as "do x when y is detected".
Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
I did this based on top of Samuel's changes dropping the MMU
requurements just in case, but I don't think there's a conflict:
https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d8a777f59402..f327a8ac648f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
depends on RISCV_ALTERNATIVE
default y
help
- Allow kernel to detect the Svnapot ISA-extension dynamically at boot
- time and enable its usage.
+ Add support for the Svnapot ISA-extension when it is detected by
+ the kernel at boot.
The Svnapot extension is used to mark contiguous PTEs as a range
of contiguous virtual-to-physical translations for a naturally
@@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
depends on RISCV_ALTERNATIVE
default y
help
- Adds support to dynamically detect the presence of the Svpbmt
- ISA-extension (Supervisor-mode: page-based memory types) and
- enable its usage.
+ Add support for the Svpbmt ISA-extension (Supervisor-mode:
+ page-based memory types) when it is detected by the kernel at
+ boot.
The memory type for a page contains a combination of attributes
that indicate the cacheability, idempotency, and ordering
@@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
depends on AS_HAS_OPTION_ARCH
config RISCV_ISA_V
- bool "VECTOR extension support"
+ bool "Vector extension support"
depends on TOOLCHAIN_HAS_V
depends on FPU
select DYNAMIC_SIGFRAME
default y
help
Say N here if you want to disable all vector related procedure
- in the kernel.
+ in the kernel. Without this option enabled, neither the kernel nor
+ userspace may use vector.
If you don't know what to do here, say Y.
@@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
depends on RISCV_ALTERNATIVE
default y
help
- Adds support to dynamically detect the presence of the ZBB
- extension (basic bit manipulation) and enable its usage.
+ Add support for enabling optimisations in the kernel when the
+ Zbb extension is detected at boot.
The Zbb extension provides instructions to accelerate a number
of bit-specific operations (count bit population, sign extending,
@@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
select RISCV_DMA_NONCOHERENT
select DMA_DIRECT_REMAP
help
- Adds support to dynamically detect the presence of the ZICBOM
- extension (Cache Block Management Operations) and enable its
- usage.
+ Add support for the Zicbom extension (Cache Block Management
+ Operations) and enable its use in the kernel when it is detected
+ at boot.
The Zicbom extension can be used to handle for example
non-coherent DMA support on devices that need it.
@@ -684,7 +685,8 @@ config FPU
default y
help
Say N here if you want to disable all floating-point related procedure
- in the kernel.
+ in the kernel. Without this option enabled, neither the kernel nor
+ userspace may use vector.
If you don't know what to do here, say Y.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-29 11:23 ` Conor Dooley
0 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-03-29 11:23 UTC (permalink / raw)
To: Conor Dooley
Cc: Stefan O'Rear, Pu Lehui, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1: Type: text/plain, Size: 4727 bytes --]
On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
> As I said on IRC to you earlier, I think the Kconfig options here are in
> need of a bit of a spring cleaning - they should be modified to explain
> their individual purposes, be that enabling optimisations in the kernel
> or being required for userspace. I'll try to send a patch for that if
> I remember tomorrow.
Something like this:
-- >8 --
commit 5125504beaedd669b082bf74b02003a77360670f
Author: Conor Dooley <conor.dooley@microchip.com>
Date: Fri Mar 29 11:13:22 2024 +0000
RISC-V: clarify what some RISCV_ISA* config options do
During some discussion on IRC yesterday and on Pu's bpf patch [1]
I noticed that these RISCV_ISA* Kconfig options are not really clear
about their implications. Many of these options have no impact on what
userspace is allowed to do, for example an application can use Zbb
regardless of whether or not the kernel does. Change the help text to
try and clarify whether or not an option affects just the kernel, or
also userspace. None of these options actually control whether or not an
extension is detected dynamically as that's done regardless of Kconfig
options, so drop any text that implies the option is required for
dynamic detection, rewording them as "do x when y is detected".
Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
I did this based on top of Samuel's changes dropping the MMU
requurements just in case, but I don't think there's a conflict:
https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d8a777f59402..f327a8ac648f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
depends on RISCV_ALTERNATIVE
default y
help
- Allow kernel to detect the Svnapot ISA-extension dynamically at boot
- time and enable its usage.
+ Add support for the Svnapot ISA-extension when it is detected by
+ the kernel at boot.
The Svnapot extension is used to mark contiguous PTEs as a range
of contiguous virtual-to-physical translations for a naturally
@@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
depends on RISCV_ALTERNATIVE
default y
help
- Adds support to dynamically detect the presence of the Svpbmt
- ISA-extension (Supervisor-mode: page-based memory types) and
- enable its usage.
+ Add support for the Svpbmt ISA-extension (Supervisor-mode:
+ page-based memory types) when it is detected by the kernel at
+ boot.
The memory type for a page contains a combination of attributes
that indicate the cacheability, idempotency, and ordering
@@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
depends on AS_HAS_OPTION_ARCH
config RISCV_ISA_V
- bool "VECTOR extension support"
+ bool "Vector extension support"
depends on TOOLCHAIN_HAS_V
depends on FPU
select DYNAMIC_SIGFRAME
default y
help
Say N here if you want to disable all vector related procedure
- in the kernel.
+ in the kernel. Without this option enabled, neither the kernel nor
+ userspace may use vector.
If you don't know what to do here, say Y.
@@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
depends on RISCV_ALTERNATIVE
default y
help
- Adds support to dynamically detect the presence of the ZBB
- extension (basic bit manipulation) and enable its usage.
+ Add support for enabling optimisations in the kernel when the
+ Zbb extension is detected at boot.
The Zbb extension provides instructions to accelerate a number
of bit-specific operations (count bit population, sign extending,
@@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
select RISCV_DMA_NONCOHERENT
select DMA_DIRECT_REMAP
help
- Adds support to dynamically detect the presence of the ZICBOM
- extension (Cache Block Management Operations) and enable its
- usage.
+ Add support for the Zicbom extension (Cache Block Management
+ Operations) and enable its use in the kernel when it is detected
+ at boot.
The Zicbom extension can be used to handle for example
non-coherent DMA support on devices that need it.
@@ -684,7 +685,8 @@ config FPU
default y
help
Say N here if you want to disable all floating-point related procedure
- in the kernel.
+ in the kernel. Without this option enabled, neither the kernel nor
+ userspace may use vector.
If you don't know what to do here, say Y.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
2024-03-29 10:10 ` Pu Lehui
@ 2024-03-29 19:46 ` Eduard Zingerman
-1 siblings, 0 replies; 60+ messages in thread
From: Eduard Zingerman @ 2024-03-29 19:46 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
[...]
> > Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
> > Could you please provide some instructions on how to prepare rootfs?
>
> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
> http://de.ports.ubuntu.com/.
Hi Pu, thank you this mirrorm it works.
Unfortunately my local setup is still not good enough.
I've installed cross-riscv64-gcc14 but it seems that a few more
libraries are necessary, as I get the following compilation errors:
$ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
... kernel compiles ok ...
../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
25 | #include <openssl/opensslv.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
In file included from nlattr.c:14:
libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
19 | #include <libelf.h>
...
Looks like I won't be able to test this patch-set, unless you have
some writeup on how to create a riscv64 dev environment at hand.
Sorry for the noise.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-29 19:46 ` Eduard Zingerman
0 siblings, 0 replies; 60+ messages in thread
From: Eduard Zingerman @ 2024-03-29 19:46 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
[...]
> > Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
> > Could you please provide some instructions on how to prepare rootfs?
>
> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
> http://de.ports.ubuntu.com/.
Hi Pu, thank you this mirrorm it works.
Unfortunately my local setup is still not good enough.
I've installed cross-riscv64-gcc14 but it seems that a few more
libraries are necessary, as I get the following compilation errors:
$ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
... kernel compiles ok ...
../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
25 | #include <openssl/opensslv.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
In file included from nlattr.c:14:
libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
19 | #include <libelf.h>
...
Looks like I won't be able to test this patch-set, unless you have
some writeup on how to create a riscv64 dev environment at hand.
Sorry for the noise.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
2024-03-29 19:46 ` Eduard Zingerman
(?)
(?)
@ 2024-03-30 10:12 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:12 UTC (permalink / raw)
To: Eduard Zingerman, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/30 3:46, Eduard Zingerman wrote:
> On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
> [...]
>
>>> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
>>> Could you please provide some instructions on how to prepare rootfs?
>>
>> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
>> http://de.ports.ubuntu.com/.
>
> Hi Pu, thank you this mirrorm it works.
>
> Unfortunately my local setup is still not good enough.
> I've installed cross-riscv64-gcc14 but it seems that a few more
> libraries are necessary, as I get the following compilation errors: >
> $ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
> ... kernel compiles ok ...
> ../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
> 25 | #include <openssl/opensslv.h>
> | ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
> In file included from nlattr.c:14:
> libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
> 19 | #include <libelf.h>
> ...
>
> Looks like I won't be able to test this patch-set, unless you have
> some writeup on how to create a riscv64 dev environment at hand.
> Sorry for the noise
Yeah, environmental issues are indeed a developer's nightmare. I will
try to do something for the newcomers of riscv64 bpf. At present, I have
simply built a docker local vmtest environment [0] based on Bjorn's
riscv-cross-builder. We can directly run vmtest within this environment.
Hopefully it will help.
Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
modified vmtest.sh to support local rootfs. And we can use it by:
```
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -l /rootfs -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
```
diff --git a/tools/testing/selftests/bpf/vmtest.sh
b/tools/testing/selftests/bpf/vmtest.sh
index f6889de9b498..17aff708c416 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -148,6 +148,21 @@ download_rootfs()
zstd -d | sudo tar -C "$dir" -x
}
+load_rootfs()
+{
+ local image_dir="$1"
+ local rootfsversion="$2"
+ local dir="$3"
+
+ if ! which zstd &> /dev/null; then
+ echo 'Could not find "zstd" on the system, please install zstd'
+ exit 1
+ fi
+
+ cat "${image_dir}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ zstd -d | sudo tar -C "$dir" -x
+}
+
recompile_kernel()
{
local kernel_checkout="$1"
@@ -234,6 +249,7 @@ EOF
create_vm_image()
{
+ local local_image_dir="$1"
local rootfs_img="${OUTPUT_DIR}/${ROOTFS_IMAGE}"
local mount_dir="${OUTPUT_DIR}/${MOUNT_DIR}"
@@ -245,7 +261,11 @@ create_vm_image()
mkfs.ext4 -q "${rootfs_img}"
mount_image
- download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ if [[ "${local_image_dir}" == "" ]]; then
+ download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ else
+ load_rootfs "${local_image_dir}" "$(newest_rootfs_version)"
"${mount_dir}"
+ fi
unmount_image
}
@@ -363,12 +383,16 @@ main()
local update_image="no"
local exit_command="poweroff -f"
local debug_shell="no"
+ local local_image_dir=""
- while getopts ':hskid:j:' opt; do
+ while getopts ':hskil:d:j:' opt; do
case ${opt} in
i)
update_image="yes"
;;
+ l)
+ local_image_dir="$OPTARG"
+ ;;
d)
OUTPUT_DIR="$OPTARG"
;;
@@ -445,7 +469,7 @@ main()
fi
if [[ "${update_image}" == "yes" ]]; then
- create_vm_image
+ create_vm_image "${local_image_dir}"
fi
update_selftests "${kernel_checkout}" "${make_command}"
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-30 10:12 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:12 UTC (permalink / raw)
To: Eduard Zingerman, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/30 3:46, Eduard Zingerman wrote:
> On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
> [...]
>
>>> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
>>> Could you please provide some instructions on how to prepare rootfs?
>>
>> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
>> http://de.ports.ubuntu.com/.
>
> Hi Pu, thank you this mirrorm it works.
>
> Unfortunately my local setup is still not good enough.
> I've installed cross-riscv64-gcc14 but it seems that a few more
> libraries are necessary, as I get the following compilation errors: >
> $ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
> ... kernel compiles ok ...
> ../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
> 25 | #include <openssl/opensslv.h>
> | ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
> In file included from nlattr.c:14:
> libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
> 19 | #include <libelf.h>
> ...
>
> Looks like I won't be able to test this patch-set, unless you have
> some writeup on how to create a riscv64 dev environment at hand.
> Sorry for the noise
Yeah, environmental issues are indeed a developer's nightmare. I will
try to do something for the newcomers of riscv64 bpf. At present, I have
simply built a docker local vmtest environment [0] based on Bjorn's
riscv-cross-builder. We can directly run vmtest within this environment.
Hopefully it will help.
Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
modified vmtest.sh to support local rootfs. And we can use it by:
```
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -l /rootfs -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
```
diff --git a/tools/testing/selftests/bpf/vmtest.sh
b/tools/testing/selftests/bpf/vmtest.sh
index f6889de9b498..17aff708c416 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -148,6 +148,21 @@ download_rootfs()
zstd -d | sudo tar -C "$dir" -x
}
+load_rootfs()
+{
+ local image_dir="$1"
+ local rootfsversion="$2"
+ local dir="$3"
+
+ if ! which zstd &> /dev/null; then
+ echo 'Could not find "zstd" on the system, please install zstd'
+ exit 1
+ fi
+
+ cat "${image_dir}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ zstd -d | sudo tar -C "$dir" -x
+}
+
recompile_kernel()
{
local kernel_checkout="$1"
@@ -234,6 +249,7 @@ EOF
create_vm_image()
{
+ local local_image_dir="$1"
local rootfs_img="${OUTPUT_DIR}/${ROOTFS_IMAGE}"
local mount_dir="${OUTPUT_DIR}/${MOUNT_DIR}"
@@ -245,7 +261,11 @@ create_vm_image()
mkfs.ext4 -q "${rootfs_img}"
mount_image
- download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ if [[ "${local_image_dir}" == "" ]]; then
+ download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ else
+ load_rootfs "${local_image_dir}" "$(newest_rootfs_version)"
"${mount_dir}"
+ fi
unmount_image
}
@@ -363,12 +383,16 @@ main()
local update_image="no"
local exit_command="poweroff -f"
local debug_shell="no"
+ local local_image_dir=""
- while getopts ':hskid:j:' opt; do
+ while getopts ':hskil:d:j:' opt; do
case ${opt} in
i)
update_image="yes"
;;
+ l)
+ local_image_dir="$OPTARG"
+ ;;
d)
OUTPUT_DIR="$OPTARG"
;;
@@ -445,7 +469,7 @@ main()
fi
if [[ "${update_image}" == "yes" ]]; then
- create_vm_image
+ create_vm_image "${local_image_dir}"
fi
update_selftests "${kernel_checkout}" "${make_command}"
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-30 10:12 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:12 UTC (permalink / raw)
To: Eduard Zingerman, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/30 3:46, Eduard Zingerman wrote:
> On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
> [...]
>
>>> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
>>> Could you please provide some instructions on how to prepare rootfs?
>>
>> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
>> http://de.ports.ubuntu.com/.
>
> Hi Pu, thank you this mirrorm it works.
>
> Unfortunately my local setup is still not good enough.
> I've installed cross-riscv64-gcc14 but it seems that a few more
> libraries are necessary, as I get the following compilation errors: >
> $ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
> ... kernel compiles ok ...
> ../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
> 25 | #include <openssl/opensslv.h>
> | ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
> In file included from nlattr.c:14:
> libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
> 19 | #include <libelf.h>
> ...
>
> Looks like I won't be able to test this patch-set, unless you have
> some writeup on how to create a riscv64 dev environment at hand.
> Sorry for the noise
Yeah, environmental issues are indeed a developer's nightmare. I will
try to do something for the newcomers of riscv64 bpf. At present, I have
simply built a docker local vmtest environment [0] based on Bjorn's
riscv-cross-builder. We can directly run vmtest within this environment.
Hopefully it will help.
Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
modified vmtest.sh to support local rootfs. And we can use it by:
```
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -l /rootfs -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
```
diff --git a/tools/testing/selftests/bpf/vmtest.sh
b/tools/testing/selftests/bpf/vmtest.sh
index f6889de9b498..17aff708c416 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -148,6 +148,21 @@ download_rootfs()
zstd -d | sudo tar -C "$dir" -x
}
+load_rootfs()
+{
+ local image_dir="$1"
+ local rootfsversion="$2"
+ local dir="$3"
+
+ if ! which zstd &> /dev/null; then
+ echo 'Could not find "zstd" on the system, please install zstd'
+ exit 1
+ fi
+
+ cat "${image_dir}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ zstd -d | sudo tar -C "$dir" -x
+}
+
recompile_kernel()
{
local kernel_checkout="$1"
@@ -234,6 +249,7 @@ EOF
create_vm_image()
{
+ local local_image_dir="$1"
local rootfs_img="${OUTPUT_DIR}/${ROOTFS_IMAGE}"
local mount_dir="${OUTPUT_DIR}/${MOUNT_DIR}"
@@ -245,7 +261,11 @@ create_vm_image()
mkfs.ext4 -q "${rootfs_img}"
mount_image
- download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ if [[ "${local_image_dir}" == "" ]]; then
+ download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ else
+ load_rootfs "${local_image_dir}" "$(newest_rootfs_version)"
"${mount_dir}"
+ fi
unmount_image
}
@@ -363,12 +383,16 @@ main()
local update_image="no"
local exit_command="poweroff -f"
local debug_shell="no"
+ local local_image_dir=""
- while getopts ':hskid:j:' opt; do
+ while getopts ':hskil:d:j:' opt; do
case ${opt} in
i)
update_image="yes"
;;
+ l)
+ local_image_dir="$OPTARG"
+ ;;
d)
OUTPUT_DIR="$OPTARG"
;;
@@ -445,7 +469,7 @@ main()
fi
if [[ "${update_image}" == "yes" ]]; then
- create_vm_image
+ create_vm_image "${local_image_dir}"
fi
update_selftests "${kernel_checkout}" "${make_command}"
X-sender: <netdev+bounces-83498-peter.schumann=secunet.com@vger.kernel.org>
X-Receiver: <peter.schumann@secunet.com> ORCPT=rfc822;peter.schumann@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAJ05ab4WgQhHsqdZ7WUjHykPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGAAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249UGV0ZXIgU2NodW1hbm41ZTcFAAsAFwC+AAAAQ5IZ35DtBUiRVnd98bETxENOPURCNCxDTj1EYXRhYmFzZXMsQ049RXhjaGFuZ2UgQWRtaW5pc3RyYXRpdmUgR3JvdXAgKEZZRElCT0hGMjNTUERMVCksQ049QWRtaW5pc3RyYXRpdmUgR3JvdXBzLENOPXNlY3VuZXQsQ049TWljcm9zb2Z0IEV4Y2hhbmdlLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUADgARAC7JU/le071Fhs0mWv1VtVsFAB0ADwAMAAAAbWJ4LWVzc2VuLTAxBQA8AAIAAA8ANgAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5EaXNwbGF5TmFtZQ8ADwAAAFNjaHVtYW5uLCBQZXRlcgUADAACAAAFAGwAAgAABQBYABcASAAAAJ05ab4WgQhHsqdZ7WUjHylDTj1TY2h1bWFubiBQZXRlcixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAU4mmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAGgAAAHBldGVyLnNjaHVtYW5uQHNlY3VuZXQuY29tBQAGAAIAAQUAKQACAAEPAAkAAABDSUF1ZGl0ZWQCAAEFAAIABwABAAAABQADAAcAAAAAAAUABQACAAEFAGIACgBOAAAA2YoAAAUAZAAPAAMAAABIdWI=
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 19236
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 11:13:28 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 11:13:28 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id 54A632025D
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 11:13:28 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable autolearn_force=no
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id IcouR_g5ZRpo for <peter.schumann@secunet.com>;
Sat, 30 Mar 2024 11:13:25 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.48.161; helo=sy.mirrors.kernel.org; envelope-from=netdev+bounces-83498-peter.schumann=secunet.com@vger.kernel.org; receiver=peter.schumann@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 85E3620315
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id 85E3620315
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 11:13:24 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 96F24B2240E
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 10:13:19 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id ADDC82838E;
Sat, 30 Mar 2024 10:13:14 +0000 (UTC)
X-Original-To: netdev@vger.kernel.org
Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id E64FAB67F;
Sat, 30 Mar 2024 10:13:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711793594; cv=none; b=bSJi2sR1AN1OJJT5964TyV+iw0AFoXsFfcNNQzQqBfdurhLo6QPOMhi4QDleME/EAEI3zHec8PyMZn2F58yTv/H2wmack6HF78DqL1FnpNS6bise3Nd9D6Y7+YaQ1kyzJwXEhdAWb4jEXr53P0FqSLruQ5QTK9CGDubbLQkdGm8=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711793594; c=relaxed/simple;
bh=JsC5VoUeo6qxef9ZMkY4tQtQ3yej/gi/YLd2vJTrgK0=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=hxarvLPRu+mk5ZdBc2p/IGRm2QUk0IROp6ZHdAtn1SLD5lufjD0LhzsDPh/tuPb5K0x5d0iwDRGKuSSkl9UjDJXD7+aG7B/m6uxajIuQmS7pVL+sDSBm5s94QtStuFDAFs9VG6lT4jV6WI5g+zDbCu92cB5/V3c/P4+nz0Ltgew=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com
Received: from mail.maildlp.com (unknown [172.19.93.142])
by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4V6ClD2Vwgz4f3js9;
Sat, 30 Mar 2024 18:12:56 +0800 (CST)
Received: from mail02.huawei.com (unknown [10.116.40.112])
by mail.maildlp.com (Postfix) with ESMTP id AD8D11A0175;
Sat, 30 Mar 2024 18:13:02 +0800 (CST)
Received: from [10.67.109.184] (unknown [10.67.109.184])
by APP1 (Coremail) with SMTP id cCh0CgBnggup5QdmbcobIg--.18079S2;
Sat, 30 Mar 2024 18:12:59 +0800 (CST)
Message-ID: <52117f9c-b691-409f-ad2a-a25f53a9433d@huaweicloud.com>
Date: Sat, 30 Mar 2024 18:12:57 +0800
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
To: Eduard Zingerman <eddyz87@gmail.com>, <bpf@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <netdev@vger.kernel.org>
CC: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>, Alexei Starovoitov
<ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko
<andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Song Liu
<song@kernel.org>, Yonghong Song <yhs@fb.com>, John Fastabend
<john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Stanislav Fomichev
<sdf@google.com>, Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
Mykola Lysenko <mykolal@fb.com>, Manu Bretelle <chantr4@gmail.com>, Pu Lehui
<pulehui@huawei.com>
References: <20240328124916.293173-1-pulehui@huaweicloud.com>
<32b3358903bf8ba408812a2636f39a275493eb91.camel@gmail.com>
<e995a1f1-0b48-4ce3-a061-5cbe68beb6dd@huaweicloud.com>
<f91237f311f183d57c4620bc2e6099df8aefccb0.camel@gmail.com>
Content-Language: en-US
From: Pu Lehui <pulehui@huaweicloud.com>
In-Reply-To: <f91237f311f183d57c4620bc2e6099df8aefccb0.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-CM-TRANSID: cCh0CgBnggup5QdmbcobIg--.18079S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWryDWry5tFy7Gw4xAFy3XFb_yoWrXw4Dpw
4xGrnFyrW0qF1fKrn7CFyUuF42gr18G347AryrGrWakwn7JFWktFnaka4Yq39Fga90q39I
yaySv343C3WUCa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2
9KBjDU0xBIdaVrnRJUUUk0b4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2
6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4
vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj
xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x
0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG
6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV
Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI
7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV
Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY
6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x
AIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv
6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUFDGOUUUUU
X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/
Return-Path: netdev+bounces-83498-peter.schumann=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 10:13:28.3828
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 7ed3d682-bc21-43ab-4d07-08dc50a20b46
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.426|SMR=0.353(SMRDE=0.004|SMRC=0.348(SMRCL=0.101|X-SMRCR=0.347))|CAT=0.071(CATRESL=0.014
(CATRESLP2R=0.002)|CATORES=0.048(CATRS=0.048(CATRS-Transport Rule
Agent=0.001|CATRS-Index Routing Agent=0.046
))|CATORT=0.004(CATRT=0.004(CATRT-Journal
Agent=0.003)));2024-03-30T10:13:28.842Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 11920
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.034|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))|SMS=0.025
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AATkLAAAPAAADH4sIAAAAAAAEAK1X+1fbyBWWwC+Mncdmn9
2enqmX1kmxbAyGgNOkm81jl3OSwAnJabdJ1itLY6wga1yNBKEJ/W/6
f/a7M5KfOJsf6iPMaHSf3/3uHfm/a+XiQcA2NzZbja3G1gbbard2au
yRG9uhy/7pBcc8HNgBOwtFxNvl4j0G6cehV1Mq1saWtbnH7Ig1d9vN
Dba+sbuxUWOHMXvC+7E3ofWqXq+/wQLXvXvs/nBohzyI/HP21h4Mzp
kruGSBiFjfPuWs6wV26GGnG3t+xHoiZKEnndOdVo1hvV8dsJ7t+QiO
RYL1vMBljghD7kRs4IWhCOvazQMR+y47FzEb+tyWnA1Dceq5nEkx4M
wLZBTGTuSJQDIRsL44I3PDkFNwLBQi6sm/kSX6Yz95CSo19nfOAs5d
FvV54pBBSUgvEuE5Ez0Wd+Mgiq2hCCNZUwE4KpQoPFe2+lE0bDcaLq
8rkbqWrzti0KhrkMjdYVyDCzs4URaivicTbwPmRexMhCcylX4ZAKQo
DuyIA1MA6gvH9pnkUTxk0JOR5/sK4GMhXMYDER/3SRlgnmoobN9HSk
4opLQStK1jx2m2UIWIHErOB5ICipjNevyMDUTIyYTvdUNdL8It4A6X
0g7Pa8yWbJ8d80gB1RO+L86oZkhz6Pk2Ac845SPbTGWBzxo7fHL/xe
OD50/vJkGwB88Pjo46Dw6eHu4/eZTuWjKW3AIF4ncWqzdOBxGXUV32
mUW3dNM55aHX83iYWAYB2QkPA+4nASBecULbI4HG6JJO6A0j2ZDecW
D1IFt32pvboHgbzANUOu42E0MeSOk3kv+n9X6bPRNMxk6fkRrR1fWI
mUKVnunP5jb7wL7zAsePwca/zlu5N5bF58N4+ct/5j+J7CSsEbrWIz
a49ZGlBw/0/0Yf7G9w1z1vEIca3WHPCvi7qBEJ4UuFHarUkNzv0VqS
QPKM+tGFvowaKDrtyz5q7oruWyVWF4m3/UCnn6Tosl4oBixAdFEIKJ
utdiKozXS8ABEHtg/8mnvzMEMK0XwiuM29KXBT3XtjHiRN80SIEwnb
Jxw0PRNBNWJdzuwuLGMOUO666YZ25PQt9FKNxQFoI1U/0qQiK2qWnI
VexNFq4zHihBzwo1NSGrv8FH136oUiGGD00dBEb+v6HGF6nas5R50S
CE/CdLn4M7f7tUklIOJJGSedhrlHU8gm09wHecIqhqh33I8GeFynpN
D15SKmDkXkChUrUkIPjnzxM/CGh5LGVhoqVZLdj2gUSnitwZLOVnqD
IeaLHsvwKxx0VDJrdAtOpfhq4w3rYu66hMsPb0UYVGW5qLxYetAoQv
GwTiPVwTGjywkXYRykFs88ClmXYsI6gPsJOfdiH+I0D2nC9bk/rBN0
T7zgpK3mrMSgPYaJuKvm6zD26WhqXBJFIwo5T0YJxU52Do/a7Ahc4g
otJw7p2ErOhknIPH18qThBp2cPH/2DYNOAlYsD4dIsctl4UEXE5CHN
/wRAbRTA4zg703BgxlFq3XO0y6+//opwPm046rl4HMQWe10uqq74WH
NPTE+fNZLkrLGuahs9VHGCHuOZO/WMPq8razcdcPpjfh4+evbzk/2j
F/U0+lkjetg5OG8st/pdlVm95gIZIpXFWVU2fnn1qi2HtsPbb978pd
GoXqqgP1phUn5tkcIHnNXMkqz6Oqiyaq06K3PrdSUpSbmI0vYAF0jG
7I8O0RHO5WL3UwWpyd+x3s7u7p7L97qtvd16vXnb7vVub+w6reYOa2
5s3N7eLhctFOyT3a+vr7NPDuH775nVbO3Wdtg6/dtsMuy44izwhe12
NF1u3poH8d8ycokqqFaM4RPZQPQBq6yhySvMekcKF4Tf+oyd9ff4S2
zo1vAG9jHvQO9uZa1ZmX2qNXHcSxx9kNick9CaW7Q/fuT12B/ZWd/D
aaIi/fM9hjey00aAiXKH2jgYy6Yf7vQFq+r3Sup39e5ZIfUKzTjqfX
kuIz6opa+cyauVclG9xOA7sKY53u95UzFSR1XW3o/yv0jOXUuXx9Kp
W2tTENSBdB3+KuzDvMPfLMr6hYqA4ZU2eU/q6NcmXeL34zprbPXDjt
PnzomIo6RCxJnNrRZxZrO1V7tNlHl08JjKzZKzsXM66KjERoani6a+
O7Oln3au84bQMR6/P3j54vDli87D/ecXjbX3zw8OXjw+6uw/vf/jo4
s5zYHAK3did0bx6cHLZ/qmQvGqVFrbyGF9c6dZayr6X5qC/gxOMMXx
PtVi1r+oeOMYtb2RnIpAqaN7k82ZtoL+TRzRNHkTM0mNb1XI9CiJi8
oUr1+9oqczAF5U2N27rFJhb94sovf/wTv36d1l1vC00UsiW+ypXFzk
inoldRAHU3Amk4VKt7WzVWtusvWtXfzfodoNbC+YLJgmRDx0qaLKwN
1KIOYYQ63aQUvg57B7tzIUZzwUNPh7c5Iu78bHHYmXET+x9BvMVrxI
KYCRhDdQ/GwS+AXCqu2+PPHc9tt2Fb82ojuo0djcZaJ+e0Z4phSYKR
hLa+/x/ALTaf65d8koH8E8BdI5l5XFsnfuXMKDW/N7U9hN9fvB4Yv7
z3+sLFYhF7N77kfCH/f5pPWPJUAMaunmb+0kc2yWP8TD8d2o/SaxSn
qPAJtoP2vG4cxQmc97RuDSVloUVxLO6JQn5ZnZfaHb2j7hKc/1xCoX
jaUlYzljGiu4jKyJW5NuMwauXM7IrxjFrFGEzLKRxX4Rl5HFLV3mct
aATo6+jTx2sgbWXxeNVSwyRnbZyOC7YKzgFuu8saLsYFEgp0YWi5xR
1k/hC7fYLBllLYZvJXANi1yqoiXhgjZNo2Tk4RqbykgBEX6bRpKj/Z
IKVT/NaI/qablsXEkDzumFFsgZq/imrE3jhpGDvH6kZTIKIiVZgAwW
KyoSvalui6tGCTFjB4mTummUlZ28aXymEsya+VVjKUdxUsBlgugGbg
uEzzd5tYlakC8T1TGAM32rLLIKpQKVa1kDklHlWDFvKBk4WkkFthFJ
0fh8yVjRYoSeaRRUmlkVkk5Bg6ByJ2CxY6ZoF5Qu9pNIjCIwv6pCxY
6uu46KZBaHpJ7eGAGoMddiWj5LKQPnrKoawTsqlgZfWVjCDm5XVVkz
Ka9UCogzh5pqdS0MMVQHi0xaQYpKpawrpQm2rMLIE2JLmvMwa6oCaR
atmmXTMExFAC2puaEwTCgNQLRfXIh81bii7avsKDaotInMec3/bKJO
aebMgrKfGxFV0T6vwxshoNLMq8CovjlCLK+T0gZzChwtmeZbnCfh9Y
TSZWz+aYIGyiNKD6i/zqg2V+4+19yeJIyy+YdlKiVi/mZZzw2C66Za
IDWA+a2yhquSUVmbplFVpZ/1uGAfOyXjSsks5wwjZ5QWiBUu3zfzNM
HMLAFrLum1ZmOBCAxC/i5DVc6okQIxIIbbVYS7SiT8MqtKRpxMFGlM
lc2ro3W6j+mUVcReUbzF4suMKm56m9MVyamaqop/lQRGo+OqRm/Mfy
CuWAR50O4L44qq5teXRVsCytfQksZXVH3dmGZRTYzCfPrKI9RXtKQa
aEmaV3XAE5nmiAB5HdvMWo3c62N85mRS3EqLSjARwHXVINhYnjByPU
tVQEhX02IV9NMvFDJ51dSpd1Qkr2+TLIxrKMGnKFKlknIXpi3kp7VK
0+5Keeom9NT1cVI4NCcSzBjXNIb6eNKQZugWM22lQKdoSQOo0kwEJg
L4TPG5qAZRRg2o0sTOUrr5eXoe0do0fj9xIG7idsIghsO2FlAII7ab
ixiSIUpfWUpBUAZLyzTEvpwo3FcT6xn8AdGVHDEzr8dvemQQjAkI/w
NdfC2YnRoAAAECngQ8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5n
PSJ1dGYtMTYiPz4NCjxUYXNrU2V0Pg0KICA8VmVyc2lvbj4xNS4wLj
AuMDwvVmVyc2lvbj4NCiAgPFRhc2tzPg0KICAgIDxUYXNrIFN0YXJ0
SW5kZXg9IjIxNSI+DQogICAgICA8VGFza1N0cmluZz4mZ3Q7Jmd0Oy
ZndDsgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIHNvbWUgaW5zdHJ1
Y3Rpb25zIG9uIGhvdyB0byBwcmVwYXJlIHJvb3Rmcz88L1Rhc2tTdH
Jpbmc+DQogICAgICA8QXNzaWduZWVzPg0KICAgICAgICA8RW1haWxV
c2VyIElkPSJlZGR5ejg3QGdtYWlsLmNvbSI+RWR1YXJkIFppbmdlcm
1hbjwvRW1haWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJi
cGZAdmdlci5rZXJuZWwub3JnIiAvPg0KICAgICAgICA8RW1haWxVc2
VyIElkPSJsaW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnIiAv
Pg0KICAgICAgICA8RW1haWxVc2VyIElkPSJuZXRkZXZAdmdlci5rZX
JuZWwub3JnIiAvPg0KICAgICAgPC9Bc3NpZ25lZXM+DQogICAgPC9U
YXNrPg0KICA8L1Rhc2tzPg0KPC9UYXNrU2V0PgELxgM8P3htbCB2ZX
JzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxVcmxTZXQ+
DQogIDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VXJscz
4NCiAgICA8VXJsIFN0YXJ0SW5kZXg9IjM3MiIgVHlwZT0iVXJsIj4N
CiAgICAgIDxVcmxTdHJpbmc+aHR0cDovL2RlLnBvcnRzLnVidW50dS
5jb20vPC9VcmxTdHJpbmc+DQogICAgPC9Vcmw+DQogICAgPFVybCBT
dGFydEluZGV4PSIxNzU2IiBUeXBlPSJVcmwiPg0KICAgICAgPFVybF
N0cmluZz5odHRwczovL2dpdGh1Yi5jb20vcHVsZWh1aS9yaXNjdi1j
cm9zcy1idWlsZGVyL3RyZWUvdm10ZXN0PC9VcmxTdHJpbmc+DQogIC
AgPC9Vcmw+DQogICAgPFVybCBTdGFydEluZGV4PSIxOTAyIiBUeXBl
PSJVcmwiPg0KICAgICAgPFVybFN0cmluZz52bXRlc3Quc2g8L1VybF
N0cmluZz4NCiAgICA8L1VybD4NCiAgPC9VcmxzPg0KPC9VcmxTZXQ+
AQ7PAVJldHJpZXZlck9wZXJhdG9yLDEwLDE7UmV0cmlldmVyT3Blcm
F0b3IsMTEsMztQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTAsMTtQb3N0
RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQb3N0V29yZEJyZWFrZXJEaW
Fnbm9zdGljT3BlcmF0b3IsMTAsNTtQb3N0V29yZEJyZWFrZXJEaWFn
bm9zdGljT3BlcmF0b3IsMTEsMDtUcmFuc3BvcnRXcml0ZXJQcm9kdW NlciwyMCwyMQ==
X-MS-Exchange-Forest-IndexAgent: 1 4099
X-MS-Exchange-Forest-EmailMessageHash: 051C196B
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
On 2024/3/30 3:46, Eduard Zingerman wrote:
> On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
> [...]
>
>>> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
>>> Could you please provide some instructions on how to prepare rootfs?
>>
>> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
>> http://de.ports.ubuntu.com/.
>
> Hi Pu, thank you this mirrorm it works.
>
> Unfortunately my local setup is still not good enough.
> I've installed cross-riscv64-gcc14 but it seems that a few more
> libraries are necessary, as I get the following compilation errors: >
> $ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
> ... kernel compiles ok ...
> ../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
> 25 | #include <openssl/opensslv.h>
> | ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
> In file included from nlattr.c:14:
> libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
> 19 | #include <libelf.h>
> ...
>
> Looks like I won't be able to test this patch-set, unless you have
> some writeup on how to create a riscv64 dev environment at hand.
> Sorry for the noise
Yeah, environmental issues are indeed a developer's nightmare. I will
try to do something for the newcomers of riscv64 bpf. At present, I have
simply built a docker local vmtest environment [0] based on Bjorn's
riscv-cross-builder. We can directly run vmtest within this environment.
Hopefully it will help.
Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
modified vmtest.sh to support local rootfs. And we can use it by:
```
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -l /rootfs -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
```
diff --git a/tools/testing/selftests/bpf/vmtest.sh
b/tools/testing/selftests/bpf/vmtest.sh
index f6889de9b498..17aff708c416 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -148,6 +148,21 @@ download_rootfs()
zstd -d | sudo tar -C "$dir" -x
}
+load_rootfs()
+{
+ local image_dir="$1"
+ local rootfsversion="$2"
+ local dir="$3"
+
+ if ! which zstd &> /dev/null; then
+ echo 'Could not find "zstd" on the system, please install zstd'
+ exit 1
+ fi
+
+ cat "${image_dir}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ zstd -d | sudo tar -C "$dir" -x
+}
+
recompile_kernel()
{
local kernel_checkout="$1"
@@ -234,6 +249,7 @@ EOF
create_vm_image()
{
+ local local_image_dir="$1"
local rootfs_img="${OUTPUT_DIR}/${ROOTFS_IMAGE}"
local mount_dir="${OUTPUT_DIR}/${MOUNT_DIR}"
@@ -245,7 +261,11 @@ create_vm_image()
mkfs.ext4 -q "${rootfs_img}"
mount_image
- download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ if [[ "${local_image_dir}" == "" ]]; then
+ download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ else
+ load_rootfs "${local_image_dir}" "$(newest_rootfs_version)"
"${mount_dir}"
+ fi
unmount_image
}
@@ -363,12 +383,16 @@ main()
local update_image="no"
local exit_command="poweroff -f"
local debug_shell="no"
+ local local_image_dir=""
- while getopts ':hskid:j:' opt; do
+ while getopts ':hskil:d:j:' opt; do
case ${opt} in
i)
update_image="yes"
;;
+ l)
+ local_image_dir="$OPTARG"
+ ;;
d)
OUTPUT_DIR="$OPTARG"
;;
@@ -445,7 +469,7 @@ main()
fi
if [[ "${update_image}" == "yes" ]]; then
- create_vm_image
+ create_vm_image "${local_image_dir}"
fi
update_selftests "${kernel_checkout}" "${make_command}"
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-03-30 10:12 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:12 UTC (permalink / raw)
To: Eduard Zingerman, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On 2024/3/30 3:46, Eduard Zingerman wrote:
> On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
> [...]
>
>>> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
>>> Could you please provide some instructions on how to prepare rootfs?
>>
>> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
>> http://de.ports.ubuntu.com/.
>
> Hi Pu, thank you this mirrorm it works.
>
> Unfortunately my local setup is still not good enough.
> I've installed cross-riscv64-gcc14 but it seems that a few more
> libraries are necessary, as I get the following compilation errors: >
> $ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
> ... kernel compiles ok ...
> ../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
> 25 | #include <openssl/opensslv.h>
> | ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
> In file included from nlattr.c:14:
> libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
> 19 | #include <libelf.h>
> ...
>
> Looks like I won't be able to test this patch-set, unless you have
> some writeup on how to create a riscv64 dev environment at hand.
> Sorry for the noise
Yeah, environmental issues are indeed a developer's nightmare. I will
try to do something for the newcomers of riscv64 bpf. At present, I have
simply built a docker local vmtest environment [0] based on Bjorn's
riscv-cross-builder. We can directly run vmtest within this environment.
Hopefully it will help.
Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
modified vmtest.sh to support local rootfs. And we can use it by:
```
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -l /rootfs -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
```
diff --git a/tools/testing/selftests/bpf/vmtest.sh
b/tools/testing/selftests/bpf/vmtest.sh
index f6889de9b498..17aff708c416 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -148,6 +148,21 @@ download_rootfs()
zstd -d | sudo tar -C "$dir" -x
}
+load_rootfs()
+{
+ local image_dir="$1"
+ local rootfsversion="$2"
+ local dir="$3"
+
+ if ! which zstd &> /dev/null; then
+ echo 'Could not find "zstd" on the system, please install zstd'
+ exit 1
+ fi
+
+ cat "${image_dir}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ zstd -d | sudo tar -C "$dir" -x
+}
+
recompile_kernel()
{
local kernel_checkout="$1"
@@ -234,6 +249,7 @@ EOF
create_vm_image()
{
+ local local_image_dir="$1"
local rootfs_img="${OUTPUT_DIR}/${ROOTFS_IMAGE}"
local mount_dir="${OUTPUT_DIR}/${MOUNT_DIR}"
@@ -245,7 +261,11 @@ create_vm_image()
mkfs.ext4 -q "${rootfs_img}"
mount_image
- download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ if [[ "${local_image_dir}" == "" ]]; then
+ download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ else
+ load_rootfs "${local_image_dir}" "$(newest_rootfs_version)"
"${mount_dir}"
+ fi
unmount_image
}
@@ -363,12 +383,16 @@ main()
local update_image="no"
local exit_command="poweroff -f"
local debug_shell="no"
+ local local_image_dir=""
- while getopts ':hskid:j:' opt; do
+ while getopts ':hskil:d:j:' opt; do
case ${opt} in
i)
update_image="yes"
;;
+ l)
+ local_image_dir="$OPTARG"
+ ;;
d)
OUTPUT_DIR="$OPTARG"
;;
@@ -445,7 +469,7 @@ main()
fi
if [[ "${update_image}" == "yes" ]]; then
- create_vm_image
+ create_vm_image "${local_image_dir}"
fi
update_selftests "${kernel_checkout}" "${make_command}"
X-sender: <netdev+bounces-83498-peter.schumann=secunet.com@vger.kernel.org>
X-Receiver: <peter.schumann@secunet.com> ORCPT=rfc822;peter.schumann@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAJ05ab4WgQhHsqdZ7WUjHykPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGAAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249UGV0ZXIgU2NodW1hbm41ZTcFAAsAFwC+AAAAQ5IZ35DtBUiRVnd98bETxENOPURCNCxDTj1EYXRhYmFzZXMsQ049RXhjaGFuZ2UgQWRtaW5pc3RyYXRpdmUgR3JvdXAgKEZZRElCT0hGMjNTUERMVCksQ049QWRtaW5pc3RyYXRpdmUgR3JvdXBzLENOPXNlY3VuZXQsQ049TWljcm9zb2Z0IEV4Y2hhbmdlLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUADgARAC7JU/le071Fhs0mWv1VtVsFAB0ADwAMAAAAbWJ4LWVzc2VuLTAxBQA8AAIAAA8ANgAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5EaXNwbGF5TmFtZQ8ADwAAAFNjaHVtYW5uLCBQZXRlcgUADAACAAAFAGwAAgAABQBYABcASAAAAJ05ab4WgQhHsqdZ7WUjHylDTj1TY2h1bWFubiBQZXRlcixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAU4mmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAGgAAAHBldGVyLnNjaHVtYW5uQHNlY3VuZXQuY29tBQAGAAIAAQUAKQACAAEPAAkAAABDSUF1ZGl0ZWQCAAEFAAIABwABAAAABQADAAcAAAAAAAUABQACAAEFAGIACgBOAAAA2YoAAAUAZAAPAAMAAABIdWI=
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 19236
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 11:13:28 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 11:13:28 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id 54A632025D
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 11:13:28 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable autolearn_force=no
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id IcouR_g5ZRpo for <peter.schumann@secunet.com>;
Sat, 30 Mar 2024 11:13:25 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.48.161; helo=sy.mirrors.kernel.org; envelope-from=netdev+bounces-83498-peter.schumann=secunet.com@vger.kernel.org; receiver=peter.schumann@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 85E3620315
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id 85E3620315
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 11:13:24 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 96F24B2240E
for <peter.schumann@secunet.com>; Sat, 30 Mar 2024 10:13:19 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id ADDC82838E;
Sat, 30 Mar 2024 10:13:14 +0000 (UTC)
X-Original-To: netdev@vger.kernel.org
Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id E64FAB67F;
Sat, 30 Mar 2024 10:13:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711793594; cv=none; b=bSJi2sR1AN1OJJT5964TyV+iw0AFoXsFfcNNQzQqBfdurhLo6QPOMhi4QDleME/EAEI3zHec8PyMZn2F58yTv/H2wmack6HF78DqL1FnpNS6bise3Nd9D6Y7+YaQ1kyzJwXEhdAWb4jEXr53P0FqSLruQ5QTK9CGDubbLQkdGm8=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711793594; c=relaxed/simple;
bh=JsC5VoUeo6qxef9ZMkY4tQtQ3yej/gi/YLd2vJTrgK0=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=hxarvLPRu+mk5ZdBc2p/IGRm2QUk0IROp6ZHdAtn1SLD5lufjD0LhzsDPh/tuPb5K0x5d0iwDRGKuSSkl9UjDJXD7+aG7B/m6uxajIuQmS7pVL+sDSBm5s94QtStuFDAFs9VG6lT4jV6WI5g+zDbCu92cB5/V3c/P4+nz0Ltgew=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com
Received: from mail.maildlp.com (unknown [172.19.93.142])
by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4V6ClD2Vwgz4f3js9;
Sat, 30 Mar 2024 18:12:56 +0800 (CST)
Received: from mail02.huawei.com (unknown [10.116.40.112])
by mail.maildlp.com (Postfix) with ESMTP id AD8D11A0175;
Sat, 30 Mar 2024 18:13:02 +0800 (CST)
Received: from [10.67.109.184] (unknown [10.67.109.184])
by APP1 (Coremail) with SMTP id cCh0CgBnggup5QdmbcobIg--.18079S2;
Sat, 30 Mar 2024 18:12:59 +0800 (CST)
Message-ID: <52117f9c-b691-409f-ad2a-a25f53a9433d@huaweicloud.com>
Date: Sat, 30 Mar 2024 18:12:57 +0800
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
To: Eduard Zingerman <eddyz87@gmail.com>, <bpf@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <netdev@vger.kernel.org>
CC: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>, Alexei Starovoitov
<ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko
<andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Song Liu
<song@kernel.org>, Yonghong Song <yhs@fb.com>, John Fastabend
<john.fastabend@gmail.com>, KP Singh <kpsingh@kernel.org>, Stanislav Fomichev
<sdf@google.com>, Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
Mykola Lysenko <mykolal@fb.com>, Manu Bretelle <chantr4@gmail.com>, Pu Lehui
<pulehui@huawei.com>
References: <20240328124916.293173-1-pulehui@huaweicloud.com>
<32b3358903bf8ba408812a2636f39a275493eb91.camel@gmail.com>
<e995a1f1-0b48-4ce3-a061-5cbe68beb6dd@huaweicloud.com>
<f91237f311f183d57c4620bc2e6099df8aefccb0.camel@gmail.com>
Content-Language: en-US
From: Pu Lehui <pulehui@huaweicloud.com>
In-Reply-To: <f91237f311f183d57c4620bc2e6099df8aefccb0.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-CM-TRANSID: cCh0CgBnggup5QdmbcobIg--.18079S2
X-Coremail-Antispam: 1UD129KBjvJXoWxWryDWry5tFy7Gw4xAFy3XFb_yoWrXw4Dpw
4xGrnFyrW0qF1fKrn7CFyUuF42gr18G347AryrGrWakwn7JFWktFnaka4Yq39Fga90q39I
yaySv343C3WUCa7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2
9KBjDU0xBIdaVrnRJUUUk0b4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2
6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4
vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj
xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x
0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG
6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV
Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI
7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV
Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY
6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x
AIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv
6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxUFDGOUUUUU
X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/
Return-Path: netdev+bounces-83498-peter.schumann=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 10:13:28.3828
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 7ed3d682-bc21-43ab-4d07-08dc50a20b46
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.426|SMR=0.353(SMRDE=0.004|SMRC=0.348(SMRCL=0.101|X-SMRCR=0.347))|CAT=0.071(CATRESL=0.014
(CATRESLP2R=0.002)|CATORES=0.048(CATRS=0.048(CATRS-Transport Rule
Agent=0.001|CATRS-Index Routing Agent=0.046
))|CATORT=0.004(CATRT=0.004(CATRT-Journal
Agent=0.003)));2024-03-30T10:13:28.842Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 11920
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.034|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))|SMS=0.025
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AATkLAAAPAAADH4sIAAAAAAAEAK1X+1fbyBWWwC+Mncdmn9
2enqmX1kmxbAyGgNOkm81jl3OSwAnJabdJ1itLY6wga1yNBKEJ/W/6
f/a7M5KfOJsf6iPMaHSf3/3uHfm/a+XiQcA2NzZbja3G1gbbard2au
yRG9uhy/7pBcc8HNgBOwtFxNvl4j0G6cehV1Mq1saWtbnH7Ig1d9vN
Dba+sbuxUWOHMXvC+7E3ofWqXq+/wQLXvXvs/nBohzyI/HP21h4Mzp
kruGSBiFjfPuWs6wV26GGnG3t+xHoiZKEnndOdVo1hvV8dsJ7t+QiO
RYL1vMBljghD7kRs4IWhCOvazQMR+y47FzEb+tyWnA1Dceq5nEkx4M
wLZBTGTuSJQDIRsL44I3PDkFNwLBQi6sm/kSX6Yz95CSo19nfOAs5d
FvV54pBBSUgvEuE5Ez0Wd+Mgiq2hCCNZUwE4KpQoPFe2+lE0bDcaLq
8rkbqWrzti0KhrkMjdYVyDCzs4URaivicTbwPmRexMhCcylX4ZAKQo
DuyIA1MA6gvH9pnkUTxk0JOR5/sK4GMhXMYDER/3SRlgnmoobN9HSk
4opLQStK1jx2m2UIWIHErOB5ICipjNevyMDUTIyYTvdUNdL8It4A6X
0g7Pa8yWbJ8d80gB1RO+L86oZkhz6Pk2Ac845SPbTGWBzxo7fHL/xe
OD50/vJkGwB88Pjo46Dw6eHu4/eZTuWjKW3AIF4ncWqzdOBxGXUV32
mUW3dNM55aHX83iYWAYB2QkPA+4nASBecULbI4HG6JJO6A0j2ZDecW
D1IFt32pvboHgbzANUOu42E0MeSOk3kv+n9X6bPRNMxk6fkRrR1fWI
mUKVnunP5jb7wL7zAsePwca/zlu5N5bF58N4+ct/5j+J7CSsEbrWIz
a49ZGlBw/0/0Yf7G9w1z1vEIca3WHPCvi7qBEJ4UuFHarUkNzv0VqS
QPKM+tGFvowaKDrtyz5q7oruWyVWF4m3/UCnn6Tosl4oBixAdFEIKJ
utdiKozXS8ABEHtg/8mnvzMEMK0XwiuM29KXBT3XtjHiRN80SIEwnb
Jxw0PRNBNWJdzuwuLGMOUO666YZ25PQt9FKNxQFoI1U/0qQiK2qWnI
VexNFq4zHihBzwo1NSGrv8FH136oUiGGD00dBEb+v6HGF6nas5R50S
CE/CdLn4M7f7tUklIOJJGSedhrlHU8gm09wHecIqhqh33I8GeFynpN
D15SKmDkXkChUrUkIPjnzxM/CGh5LGVhoqVZLdj2gUSnitwZLOVnqD
IeaLHsvwKxx0VDJrdAtOpfhq4w3rYu66hMsPb0UYVGW5qLxYetAoQv
GwTiPVwTGjywkXYRykFs88ClmXYsI6gPsJOfdiH+I0D2nC9bk/rBN0
T7zgpK3mrMSgPYaJuKvm6zD26WhqXBJFIwo5T0YJxU52Do/a7Ahc4g
otJw7p2ErOhknIPH18qThBp2cPH/2DYNOAlYsD4dIsctl4UEXE5CHN
/wRAbRTA4zg703BgxlFq3XO0y6+//opwPm046rl4HMQWe10uqq74WH
NPTE+fNZLkrLGuahs9VHGCHuOZO/WMPq8razcdcPpjfh4+evbzk/2j
F/U0+lkjetg5OG8st/pdlVm95gIZIpXFWVU2fnn1qi2HtsPbb978pd
GoXqqgP1phUn5tkcIHnNXMkqz6Oqiyaq06K3PrdSUpSbmI0vYAF0jG
7I8O0RHO5WL3UwWpyd+x3s7u7p7L97qtvd16vXnb7vVub+w6reYOa2
5s3N7eLhctFOyT3a+vr7NPDuH775nVbO3Wdtg6/dtsMuy44izwhe12
NF1u3poH8d8ycokqqFaM4RPZQPQBq6yhySvMekcKF4Tf+oyd9ff4S2
zo1vAG9jHvQO9uZa1ZmX2qNXHcSxx9kNick9CaW7Q/fuT12B/ZWd/D
aaIi/fM9hjey00aAiXKH2jgYy6Yf7vQFq+r3Sup39e5ZIfUKzTjqfX
kuIz6opa+cyauVclG9xOA7sKY53u95UzFSR1XW3o/yv0jOXUuXx9Kp
W2tTENSBdB3+KuzDvMPfLMr6hYqA4ZU2eU/q6NcmXeL34zprbPXDjt
PnzomIo6RCxJnNrRZxZrO1V7tNlHl08JjKzZKzsXM66KjERoani6a+
O7Oln3au84bQMR6/P3j54vDli87D/ecXjbX3zw8OXjw+6uw/vf/jo4
s5zYHAK3did0bx6cHLZ/qmQvGqVFrbyGF9c6dZayr6X5qC/gxOMMXx
PtVi1r+oeOMYtb2RnIpAqaN7k82ZtoL+TRzRNHkTM0mNb1XI9CiJi8
oUr1+9oqczAF5U2N27rFJhb94sovf/wTv36d1l1vC00UsiW+ypXFzk
inoldRAHU3Amk4VKt7WzVWtusvWtXfzfodoNbC+YLJgmRDx0qaLKwN
1KIOYYQ63aQUvg57B7tzIUZzwUNPh7c5Iu78bHHYmXET+x9BvMVrxI
KYCRhDdQ/GwS+AXCqu2+PPHc9tt2Fb82ojuo0djcZaJ+e0Z4phSYKR
hLa+/x/ALTaf65d8koH8E8BdI5l5XFsnfuXMKDW/N7U9hN9fvB4Yv7
z3+sLFYhF7N77kfCH/f5pPWPJUAMaunmb+0kc2yWP8TD8d2o/SaxSn
qPAJtoP2vG4cxQmc97RuDSVloUVxLO6JQn5ZnZfaHb2j7hKc/1xCoX
jaUlYzljGiu4jKyJW5NuMwauXM7IrxjFrFGEzLKRxX4Rl5HFLV3mct
aATo6+jTx2sgbWXxeNVSwyRnbZyOC7YKzgFuu8saLsYFEgp0YWi5xR
1k/hC7fYLBllLYZvJXANi1yqoiXhgjZNo2Tk4RqbykgBEX6bRpKj/Z
IKVT/NaI/qablsXEkDzumFFsgZq/imrE3jhpGDvH6kZTIKIiVZgAwW
KyoSvalui6tGCTFjB4mTummUlZ28aXymEsya+VVjKUdxUsBlgugGbg
uEzzd5tYlakC8T1TGAM32rLLIKpQKVa1kDklHlWDFvKBk4WkkFthFJ
0fh8yVjRYoSeaRRUmlkVkk5Bg6ByJ2CxY6ZoF5Qu9pNIjCIwv6pCxY
6uu46KZBaHpJ7eGAGoMddiWj5LKQPnrKoawTsqlgZfWVjCDm5XVVkz
Ka9UCogzh5pqdS0MMVQHi0xaQYpKpawrpQm2rMLIE2JLmvMwa6oCaR
atmmXTMExFAC2puaEwTCgNQLRfXIh81bii7avsKDaotInMec3/bKJO
aebMgrKfGxFV0T6vwxshoNLMq8CovjlCLK+T0gZzChwtmeZbnCfh9Y
TSZWz+aYIGyiNKD6i/zqg2V+4+19yeJIyy+YdlKiVi/mZZzw2C66Za
IDWA+a2yhquSUVmbplFVpZ/1uGAfOyXjSsks5wwjZ5QWiBUu3zfzNM
HMLAFrLum1ZmOBCAxC/i5DVc6okQIxIIbbVYS7SiT8MqtKRpxMFGlM
lc2ro3W6j+mUVcReUbzF4suMKm56m9MVyamaqop/lQRGo+OqRm/Mfy
CuWAR50O4L44qq5teXRVsCytfQksZXVH3dmGZRTYzCfPrKI9RXtKQa
aEmaV3XAE5nmiAB5HdvMWo3c62N85mRS3EqLSjARwHXVINhYnjByPU
tVQEhX02IV9NMvFDJ51dSpd1Qkr2+TLIxrKMGnKFKlknIXpi3kp7VK
0+5Keeom9NT1cVI4NCcSzBjXNIb6eNKQZugWM22lQKdoSQOo0kwEJg
L4TPG5qAZRRg2o0sTOUrr5eXoe0do0fj9xIG7idsIghsO2FlAII7ab
ixiSIUpfWUpBUAZLyzTEvpwo3FcT6xn8AdGVHDEzr8dvemQQjAkI/w
NdfC2YnRoAAAECngQ8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5n
PSJ1dGYtMTYiPz4NCjxUYXNrU2V0Pg0KICA8VmVyc2lvbj4xNS4wLj
AuMDwvVmVyc2lvbj4NCiAgPFRhc2tzPg0KICAgIDxUYXNrIFN0YXJ0
SW5kZXg9IjIxNSI+DQogICAgICA8VGFza1N0cmluZz4mZ3Q7Jmd0Oy
ZndDsgQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIHNvbWUgaW5zdHJ1
Y3Rpb25zIG9uIGhvdyB0byBwcmVwYXJlIHJvb3Rmcz88L1Rhc2tTdH
Jpbmc+DQogICAgICA8QXNzaWduZWVzPg0KICAgICAgICA8RW1haWxV
c2VyIElkPSJlZGR5ejg3QGdtYWlsLmNvbSI+RWR1YXJkIFppbmdlcm
1hbjwvRW1haWxVc2VyPg0KICAgICAgICA8RW1haWxVc2VyIElkPSJi
cGZAdmdlci5rZXJuZWwub3JnIiAvPg0KICAgICAgICA8RW1haWxVc2
VyIElkPSJsaW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnIiAv
Pg0KICAgICAgICA8RW1haWxVc2VyIElkPSJuZXRkZXZAdmdlci5rZX
JuZWwub3JnIiAvPg0KICAgICAgPC9Bc3NpZ25lZXM+DQogICAgPC9U
YXNrPg0KICA8L1Rhc2tzPg0KPC9UYXNrU2V0PgELxgM8P3htbCB2ZX
JzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxVcmxTZXQ+
DQogIDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VXJscz
4NCiAgICA8VXJsIFN0YXJ0SW5kZXg9IjM3MiIgVHlwZT0iVXJsIj4N
CiAgICAgIDxVcmxTdHJpbmc+aHR0cDovL2RlLnBvcnRzLnVidW50dS
5jb20vPC9VcmxTdHJpbmc+DQogICAgPC9Vcmw+DQogICAgPFVybCBT
dGFydEluZGV4PSIxNzU2IiBUeXBlPSJVcmwiPg0KICAgICAgPFVybF
N0cmluZz5odHRwczovL2dpdGh1Yi5jb20vcHVsZWh1aS9yaXNjdi1j
cm9zcy1idWlsZGVyL3RyZWUvdm10ZXN0PC9VcmxTdHJpbmc+DQogIC
AgPC9Vcmw+DQogICAgPFVybCBTdGFydEluZGV4PSIxOTAyIiBUeXBl
PSJVcmwiPg0KICAgICAgPFVybFN0cmluZz52bXRlc3Quc2g8L1VybF
N0cmluZz4NCiAgICA8L1VybD4NCiAgPC9VcmxzPg0KPC9VcmxTZXQ+
AQ7PAVJldHJpZXZlck9wZXJhdG9yLDEwLDE7UmV0cmlldmVyT3Blcm
F0b3IsMTEsMztQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTAsMTtQb3N0
RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQb3N0V29yZEJyZWFrZXJEaW
Fnbm9zdGljT3BlcmF0b3IsMTAsNTtQb3N0V29yZEJyZWFrZXJEaWFn
bm9zdGljT3BlcmF0b3IsMTEsMDtUcmFuc3BvcnRXcml0ZXJQcm9kdW NlciwyMCwyMQ==
X-MS-Exchange-Forest-IndexAgent: 1 4099
X-MS-Exchange-Forest-EmailMessageHash: 051C196B
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
On 2024/3/30 3:46, Eduard Zingerman wrote:
> On Fri, 2024-03-29 at 18:10 +0800, Pu Lehui wrote:
> [...]
>
>>> Apparently jammy does not have binaries built for riscv64, or I'm failing to find correct mirror.
>>> Could you please provide some instructions on how to prepare rootfs?
>>
>> Hi Eduard, We need the mirror repository of ubuntu-ports, you could try
>> http://de.ports.ubuntu.com/.
>
> Hi Pu, thank you this mirrorm it works.
>
> Unfortunately my local setup is still not good enough.
> I've installed cross-riscv64-gcc14 but it seems that a few more
> libraries are necessary, as I get the following compilation errors: >
> $ PLATFORM=riscv64 CROSS_COMPILE=riscv64-suse-linux- ./vmtest.sh -- ./test_verifier
> ... kernel compiles ok ...
> ../../../../scripts/sign-file.c:25:10: fatal error: openssl/opensslv.h: No such file or directory
> 25 | #include <openssl/opensslv.h>
> | ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> CC /home/eddy/work/bpf-next/tools/testing/selftests/bpf/tools/build/host/libbpf/sharedobjs/bpf.o
> In file included from nlattr.c:14:
> libbpf_internal.h:19:10: fatal error: libelf.h: No such file or directory
> 19 | #include <libelf.h>
> ...
>
> Looks like I won't be able to test this patch-set, unless you have
> some writeup on how to create a riscv64 dev environment at hand.
> Sorry for the noise
Yeah, environmental issues are indeed a developer's nightmare. I will
try to do something for the newcomers of riscv64 bpf. At present, I have
simply built a docker local vmtest environment [0] based on Bjorn's
riscv-cross-builder. We can directly run vmtest within this environment.
Hopefully it will help.
Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
modified vmtest.sh to support local rootfs. And we can use it by:
```
PLATFORM=riscv64 CROSS_COMPILE=riscv64-linux-gnu- \
tools/testing/selftests/bpf/vmtest.sh -l /rootfs -- \
./test_progs -d \
\"$(cat tools/testing/selftests/bpf/DENYLIST.riscv64 \
| cut -d'#' -f1 \
| sed -e 's/^[[:space:]]*//' \
-e 's/[[:space:]]*$//' \
| tr -s '\n' ','\
)\"
```
diff --git a/tools/testing/selftests/bpf/vmtest.sh
b/tools/testing/selftests/bpf/vmtest.sh
index f6889de9b498..17aff708c416 100755
--- a/tools/testing/selftests/bpf/vmtest.sh
+++ b/tools/testing/selftests/bpf/vmtest.sh
@@ -148,6 +148,21 @@ download_rootfs()
zstd -d | sudo tar -C "$dir" -x
}
+load_rootfs()
+{
+ local image_dir="$1"
+ local rootfsversion="$2"
+ local dir="$3"
+
+ if ! which zstd &> /dev/null; then
+ echo 'Could not find "zstd" on the system, please install zstd'
+ exit 1
+ fi
+
+ cat "${image_dir}/libbpf-vmtest-rootfs-$rootfsversion.tar.zst" |
+ zstd -d | sudo tar -C "$dir" -x
+}
+
recompile_kernel()
{
local kernel_checkout="$1"
@@ -234,6 +249,7 @@ EOF
create_vm_image()
{
+ local local_image_dir="$1"
local rootfs_img="${OUTPUT_DIR}/${ROOTFS_IMAGE}"
local mount_dir="${OUTPUT_DIR}/${MOUNT_DIR}"
@@ -245,7 +261,11 @@ create_vm_image()
mkfs.ext4 -q "${rootfs_img}"
mount_image
- download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ if [[ "${local_image_dir}" == "" ]]; then
+ download_rootfs "$(newest_rootfs_version)" "${mount_dir}"
+ else
+ load_rootfs "${local_image_dir}" "$(newest_rootfs_version)"
"${mount_dir}"
+ fi
unmount_image
}
@@ -363,12 +383,16 @@ main()
local update_image="no"
local exit_command="poweroff -f"
local debug_shell="no"
+ local local_image_dir=""
- while getopts ':hskid:j:' opt; do
+ while getopts ':hskil:d:j:' opt; do
case ${opt} in
i)
update_image="yes"
;;
+ l)
+ local_image_dir="$OPTARG"
+ ;;
d)
OUTPUT_DIR="$OPTARG"
;;
@@ -445,7 +469,7 @@ main()
fi
if [[ "${update_image}" == "yes" ]]; then
- create_vm_image
+ create_vm_image "${local_image_dir}"
fi
update_selftests "${kernel_checkout}" "${make_command}"
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-29 11:23 ` Conor Dooley
(?)
(?)
@ 2024-03-30 10:19 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:19 UTC (permalink / raw)
To: Conor Dooley
Cc: Stefan O'Rear, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Thanks for the clarification, looks good.
On 2024/3/29 19:23, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-30 10:19 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:19 UTC (permalink / raw)
To: Conor Dooley
Cc: Stefan O'Rear, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Thanks for the clarification, looks good.
On 2024/3/29 19:23, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
>
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-30 10:19 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:19 UTC (permalink / raw)
To: Conor Dooley
Cc: Stefan O'Rear, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Thanks for the clarification, looks good.
On 2024/3/29 19:23, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
>
X-sender: <netdev+bounces-83499-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAU4mmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAGQAAADZigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 21009
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 11:19:50 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 11:19:50 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id DA4E3202BE
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 11:19:50 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable autolearn_force=no
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 19NrXs2x69LU for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 11:19:49 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.80.249; helo=am.mirrors.kernel.org; envelope-from=netdev+bounces-83499-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com D53502025D
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id D53502025D
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 11:19:49 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 5FB3D1F22438
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 10:19:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8F26528DDF;
Sat, 30 Mar 2024 10:19:41 +0000 (UTC)
X-Original-To: netdev@vger.kernel.org
Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AE2C11712;
Sat, 30 Mar 2024 10:19:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711793981; cv=none; b=XjBCD05gp0RzPexcO+ruoj3Fvp0FHXH+g1yfSbBCSauFIO1tUJvCAj18ickaY2KtMh11GdCoGwv3yLyQZoDDBinyTfTzxZ5XaxHx7XGBoBo5iGdcqn7ARJxFLji2YUWRwxjWGn6aW3Oinox5cToQXAPElCFyZ7MFApmpor1VULY=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711793981; c=relaxed/simple;
bh=Kj8wuHAHZVd+Kvn7QFiN9E4M/87APJxMIBq/ikHQ35Y=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=ilzO63a9w9glrMWlidF2JyKlGjQXsTBHUwYWqKLjURwPleSvCK0pu0qEQdVpkPgBj5Tx3dxnOZS852pfce8pAD873pPxN2FP6XW++Ruqeqw5s1oHFlXc5dC6RReHxltRJkkBQ+ajCbNKwPRUITLQoWw6vma09F/1Pl3fF0oK81s=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com
Received: from mail.maildlp.com (unknown [172.19.163.235])
by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4V6Ctd17Lrz4f3lgL;
Sat, 30 Mar 2024 18:19:21 +0800 (CST)
Received: from mail02.huawei.com (unknown [10.116.40.75])
by mail.maildlp.com (Postfix) with ESMTP id 64B191A0568;
Sat, 30 Mar 2024 18:19:29 +0800 (CST)
Received: from [10.67.109.184] (unknown [10.67.109.184])
by APP2 (Coremail) with SMTP id Syh0CgCXug0s5wdmXWTTIg--.19989S2;
Sat, 30 Mar 2024 18:19:25 +0800 (CST)
Message-ID: <95e1978f-341c-4de5-a665-e057fe97a060@huaweicloud.com>
Date: Sat, 30 Mar 2024 18:19:24 +0800
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb
instructions
Content-Language: en-US
To: Conor Dooley <conor@kernel.org>
CC: Stefan O'Rear <sorear@fastmail.com>, <bpf@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <netdev@vger.kernel.org>,
=?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>, Alexei Starovoitov
<ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko
<andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Eduard
Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>, Yonghong Song
<yhs@fb.com>, John Fastabend <john.fastabend@gmail.com>, KP Singh
<kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo
<haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko
<mykolal@fb.com>, Manu Bretelle <chantr4@gmail.com>, Pu Lehui
<pulehui@huawei.com>
References: <20240328124916.293173-1-pulehui@huaweicloud.com>
<20240328124916.293173-3-pulehui@huaweicloud.com>
<3ed9fe94-2610-41eb-8a00-a9f37fcf2b1a@app.fastmail.com>
<20240328-ferocity-repose-c554f75a676c@spud>
<20240329-linguini-uncured-380cb4cff61c@wendy>
From: Pu Lehui <pulehui@huaweicloud.com>
In-Reply-To: <20240329-linguini-uncured-380cb4cff61c@wendy>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-CM-TRANSID: Syh0CgCXug0s5wdmXWTTIg--.19989S2
X-Coremail-Antispam: 1UD129KBjvJXoWxur4UGFW5XF4UXrWDGFW5GFg_yoWrtF4DpF
WfKF1xKFn7Jw1fZ393Xw18Wr1093Z7Kw43GrykG34Fy343ur1xGw1qy3ZrXFyDZrn3Gr1a
v390gF1q93WUCFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2
9KBjDU0xBIdaVrnRJUUUkYb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2
6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4
vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj
xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x
0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG
6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV
Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI
7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV
Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY
6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x
AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280
aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IUbG2NtUUUUU==
X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/
Return-Path: netdev+bounces-83499-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 10:19:50.9305
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 922a0c38-9365-43f6-727c-08dc50a2ef4a
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.192|SMR=0.113(SMRDE=0.003|SMRC=0.109(SMRCL=0.108|X-SMRCR=0.065))|CAT=0.078(CATOS=0.001
|CATRESL=0.027(CATRESLP2R=0.021)|CATORES=0.047(CATRS=0.047(CATRS-Transport
Rule Agent=0.001 (X-ETREX=0.001)|CATRS-Index Routing
Agent=0.045)));2024-03-30T10:19:51.131Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 12913
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.008|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAUILAAAPAAADH4sIAAAAAAAEAN1Ya2/byBUdWbJsS34lu9
lF+2mQL9ndSLIsP2MUiziOtxG6fsB2vdgUhUGRI4s1xeHy4UT/oz+4
Z+4lKdKPJC26QFFBkYfDO/dx7rl3ZvLP7y9Gln8TyaEOZTxS0vas0B
26thW72m9JT2u8vNba6Sw1lhonvux1e5trG2u9V3L91V5voyUPtI+1
b7X21ER+CHWs9pYaP0qIXoySljyyQtnbbdE6acVyvbvX3cHC0yP5so
vPYwrw/VHuR7IvI8t1pPZl/+xAxlpOdCKVFXquClt4G49c/4Zc/4ut
/aF7LXVgfI/kSIVKWvjn+qTMVwp6htKSAzfmQRSErn+NoJXlm0HbKJ
rIaKQTz5EDJcfaARpYB8PqY+BZqS6IuSEUO+6t6ySWJ4MkDHSkopZZ
FY8QqPKtgWeUGn/GbmSxV65Pzt6o0Fce6ULwA2UEQ/Vb4oYwZpKRRC
qMAstWHdl/4XkyDifGiUj5DhwPrNgepUmDLXdImvpQMVbjgcK0Husw
1B86DKU812NloLqWnntjPHSjFGXZbssfd/FrxrYejwHO1npva6u7OV
CWcpzt7VeD7m5vMNzZHHR73e6GtbOzsd3d3ukaq3I/iUc63Cun8U+2
eeo49PR67Nqhtkdu0IF+svnWQpallD+FLjMEdFrfW9/Y6/WYKcSN1E
H6nPXPD9qXeylBQRQTd4So6M3lVf98/wd5hwGOLmp4m1CyaY3jRnYS
RZDKmDVRUaxCx5pIyye6nSYvIjkIhinWf1v/e66pL30du7ahhfEC+Y
xKbtxloiEhViA7ludNiG5hrswa6CTOCDUOvLT2og6A8SeGp6w/p7V1
a7QZWcuOjacGilxdzhvpwrDn6Q/MXke3iC/qowUjKAxfWkFuTdp4xl
L5fjDIVYXq2godT0WR8eLDCAQCs6DDxDIlMVQreHuARnKtaH6kvEDG
6iOkdK7NENhAO01gSR/sc4TSGg6VHUfyH0lUNNOC5BQ0L9LFEjnWvr
oPFfBJGHHtx6H27tvMFcJZ5RMfAJujYngA3JyJb4G8pMOKKNsvDK1g
rAxOmvFcXepBC2yTTqgDaVLJiFC9mjyriKJLo4bZYv3nmlIXUp+oKY
fqgw4dw2WsHxvHnjtafjTR+XJSDOB5p1gAP6NT7slRHAfR3tqap0PV
YWg7OrxeQ69KPrZDFMbtminB7kZvtz1UKFw3nrRDZdpb297a2hzubF
nbO9v26yhInLVSYZy7175y2no4bA8m/2ZLoE+b21BaZY7rUKeSAytS
VJQxoATc59Y4UR5SYRPpIsI4SBGRR0d/LXD4tyQxXdHPGOUaskcKjR
pl1zfJfBFPd5FQQatFjQS1Ee/lir4Ytl5vBz1ye6Pbwc/m1sZGe7Md
kb+dkfY8lMDrCHvKrTKRr6X5wS4zRPDX6L3WmhXaozXWmHWSwQOTZh
12IPVROrtoyTvDrVew3ukMN3o71q5lb2/uDrHddrc3N7nNtx/Ubd69
fPnyUROvX8v2Vne9tStf8h9MpF7lLe/q/PJ4//TkIkcLDAywU0UmZy
y1//PF4dnx/kX/8rAoNbQSL5aT6ZTpHeRu+rxvWljWaUwfI2pTns9v
fStAGcOB9rR+SzUby4HWcVEf9mJFfYj2Z3RJ8CKJrGvVISAyq44joy
QIdBjnR6OHzVHRIW3FtjGYFHUVOmXqT6kq8bkoaC81oiTi5j22whtq
Yu51opNInl4cRqbuLRka/hd1oToKgrduaFpgO9btYDSJDCxoxJYfee
lxxARnSd+Kk9Aglie81229QsLpz8MJP31z9Hvk20Af5dibhBfyWUh+
EKLT+3bW9YFfMBiXMn0nUd+dJ4EKb91Ih20c63D8CJD1NrcWnJq0OW
BNAhV9b+hRUvRJqjzCFePN5zwoqXnUm4cZVqZVSdNDFCOOFfSmiTdG
iS842HLfGw9cn48E5oQcx6GLPqmiki7ew3D4xeGBd3zbskfKGrge9o
qWdB01BpeRHjzQcSp0lDl85fTaXG+t45BHf7cKBLs4Ofn54N1+//jq
3f751eWD/MIL8/Lk9KJ/cny1f3bwLo/1Hk0vp3kEKp58fnl4cHFyVq
iyNHPPpwimggCajksPCd7z6Uv8/ul0ui3hHO8ZJr/99Xj/qH9wdd7/
809n+0dfVirZ5xyH1WO+5rhDuhd9sHyuGVw3DGNRNPKWAwkVSh7MCb
DtKgdbYpHhpUtJid3lN/IXF4d9Oq6CjenJhavDaeGC5dLpqsBMn08y
mbbp4XQM3815k727y9Y+h8N7842PDYCO+3SMpYBxsIKCX7N1hlO4kZ
g9aru788ge9f7Nm/+hfpV6M+0x0zaBJoADn7mkjnEtDRLu1d9/fte6
14q+5A7K/QXPJU24BzxyJn5kD6MGU14FquF2rIy9KA4Tm40DIsu2Qf
/QNA/sPYm5sJZUASJE344CZZv/i4D3RphWf2frBBw34AQ6gwZswMGT
LZtzcSvnRG/DbGPbvc1HtrH3/YM3J0f3ypIF3h7tXx2fHB+cvDs8Oz
y+uF+8eP+2f4aOcnV2eLR/+juQJHfvIZ4cmKYr33javjF3RbDBHHPl
SY7WXcqUFH3hTvbetQd6/HmzJUWPu0BF/wD/yvtbSdknCXfXO3OPHa
j84ITrAe5oxYtvSYWv/batTUPxKZ159OYcqW5xxedLH//fkUs+MLF2
N1s7INbuVqnZlFr8f62DDz0NMP3rdqBdP/6/7uTmPxmXGkLUxVxV1P
BdEiuzol4TCzOiWquIBXzFbEXMzFSqs0LMijm8rZvfBgSqYrZaEYv4
itqMqNXELMTmK2Je4Dt/b8kylkCVETNra/w7Z4zMQIbG8/hCgN7OsS
TesjAG0DMvmpjHADPz5OecWMTyhmjOk1d4i/klMoeFddHEAAKYxOMC
LWeFNQqNTZOtOTxCbF6sLogGZmqV1YoQCAjmvhOtupinWOax7I8UFM
SqxuF5g14FOsUUgcpCTYhaZZZAeAIw68ZclQPEd9ZgC9MmFkzOiOU6
hdwgh8nVRu4nBrOVOXKmCSdZCZzJlTB0nERG27wV9UWxzDBizKswZv
RqYmmBECPr1Rlay+OmWGRVVbHI/vB8rr9G4TNupLNZzZbnkmwoT2jd
zBvwOQW5SwC8vKrJXmEebrCSHJY5sTrH5CSdbJ0DzykBnzGzQHrIUC
0nnmGykfmmRtCdkG8cCMNF2V/AzKJYqmWA1ytiiWRmSOweAf7AFOWM
5LFzXMw6uGQUUtQ14hsTjxEg1j2Fzl/u+bMsVliAkaRXQG+ONbBFFs
jGTU76YmWpbup6ufBqZTquLDM5TYCVmemYrGP0JK3HJ5wXnmmKZ2QL
DqxyUXN2OO9Vg5IhLWcNMlneOZynqVjGk1yeYcnKeTlPZU18zZILWV
3zbyPjD2H4BAPMIFVfkatQAqgZn4XK6qfDXKUw64ZUD4b5hNnFFcGB
cM+hVV9lITQbFbFi5Ouw2iCEqQYhv5qF/1UxfDN5d+3TO2vLsFQzWF
Zq4llWg7M5DeapizLyDfEtz+AtmNAkNOYrKxw+96jpmGlsfGiQtmba
DSriaWYUjYLhaqbUbdYy8s/B7cKY197XViUNcwZwVMTTnEW5/xwgD/
JyptQ/y9HOBukeQQILuXBVrHDDpMdvWJj2stkcybT0KoufZsUSicHn
/4AVVbN3NHlPWczIfIcA5e2J87jKDT9PN2eZJ5nSzHNqBQQFbbt41a
DtD5IYmO5aefKFnOfHZ/SI6JiTq+n2sfJZ8nOYvPM2aL8gmdX7VC9I
fluQrOVngHqJ7c/y8LMGW8vLP+s2X+fh53tWvrHOVBqfQIDT+ln6QW
JZLHB3/V1I+C/a/EeECx4AAAEK4QE8P3htbCB2ZXJzaW9uPSIxLjAi
IGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxFbWFpbFNldD4NCiAgPFZlcn
Npb24+MTUuMC4wLjA8L1ZlcnNpb24+DQogIDxFbWFpbHM+DQogICAg
PEVtYWlsIFN0YXJ0SW5kZXg9IjU5OSI+DQogICAgICA8RW1haWxTdH
Jpbmc+Y29ub3IuZG9vbGV5QG1pY3JvY2hpcC5jb208L0VtYWlsU3Ry
aW5nPg0KICAgIDwvRW1haWw+DQogIDwvRW1haWxzPg0KPC9FbWFpbF
NldD4BC7wDPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRm
LTE2Ij8+DQo8VXJsU2V0Pg0KICA8VmVyc2lvbj4xNS4wLjAuMDwvVm
Vyc2lvbj4NCiAgPFVybHM+DQogICAgPFVybCBTdGFydEluZGV4PSIx
NTIxIiBUeXBlPSJVcmwiPg0KICAgICAgPFVybFN0cmluZz5odHRwcz
ovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi8yMDI0MDMyOC1m
ZXJvY2l0eS1yZXBvc2UtYzU1NGY3NWE2NzZjQHNwdWQvPC9VcmxTdH
Jpbmc+DQogICAgPC9Vcmw+DQogICAgPFVybCBTdGFydEluZGV4PSIx
ODMyIiBUeXBlPSJVcmwiPg0KICAgICAgPFVybFN0cmluZz5odHRwcz
ovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi8yMDI0MDIyNzAw
MzYzMC4zNjM0NTMzLTQtc2FtdWVsLmhvbGxhbmRAc2lmaXZlLmNvbS
88L1VybFN0cmluZz4NCiAgICA8L1VybD4NCiAgPC9VcmxzPg0KPC9V
cmxTZXQ+AQz9Bjw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9In
V0Zi0xNiI/Pg0KPENvbnRhY3RTZXQ+DQogIDxWZXJzaW9uPjE1LjAu
MC4wPC9WZXJzaW9uPg0KICA8Q29udGFjdHM+DQogICAgPENvbnRhY3
QgU3RhcnRJbmRleD0iNTg1Ij4NCiAgICAgIDxQZXJzb24gU3RhcnRJ
bmRleD0iNTg1Ij4NCiAgICAgICAgPFBlcnNvblN0cmluZz5Db25vci
BEb29sZXk8L1BlcnNvblN0cmluZz4NCiAgICAgIDwvUGVyc29uPg0K
ICAgICAgPEVtYWlscz4NCiAgICAgICAgPEVtYWlsIFN0YXJ0SW5kZX
g9IjU5OSI+DQogICAgICAgICAgPEVtYWlsU3RyaW5nPmNvbm9yLmRv
b2xleUBtaWNyb2NoaXAuY29tPC9FbWFpbFN0cmluZz4NCiAgICAgIC
AgPC9FbWFpbD4NCiAgICAgIDwvRW1haWxzPg0KICAgICAgPENvbnRh
Y3RTdHJpbmc+Q29ub3IgRG9vbGV5ICZsdDtjb25vci5kb29sZXlAbW
ljcm9jaGlwLmNvbTwvQ29udGFjdFN0cmluZz4NCiAgICA8L0NvbnRh
Y3Q+DQogICAgPENvbnRhY3QgU3RhcnRJbmRleD0iMTYyOCI+DQogIC
AgICA8UGVyc29uIFN0YXJ0SW5kZXg9IjE2MjgiPg0KICAgICAgICA8
UGVyc29uU3RyaW5nPkNvbm9yIERvb2xleTwvUGVyc29uU3RyaW5nPg
0KICAgICAgPC9QZXJzb24+DQogICAgICA8RW1haWxzPg0KICAgICAg
ICA8RW1haWwgU3RhcnRJbmRleD0iMTY0MiI+DQogICAgICAgICAgPE
VtYWlsU3RyaW5nPmNvbm9yLmRvb2xleUBtaWNyb2NoaXAuY29tPC9F
bWFpbFN0cmluZz4NCiAgICAgICAgPC9FbWFpbD4NCiAgICAgIDwvRW
1haWxzPg0KICAgICAgPENvbnRhY3RTdHJpbmc+Q29ub3IgRG9vbGV5
ICZsdDtjb25vci5kb29sZXlAbWljcm9jaGlwLmNvbTwvQ29udGFjdF
N0cmluZz4NCiAgICA8L0NvbnRhY3Q+DQogIDwvQ29udGFjdHM+DQo8
L0NvbnRhY3RTZXQ+AQ7PAVJldHJpZXZlck9wZXJhdG9yLDEwLDI7Um
V0cmlldmVyT3BlcmF0b3IsMTEsMjtQb3N0RG9jUGFyc2VyT3BlcmF0
b3IsMTAsMTtQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQb3N0V2
9yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTAsNTtQb3N0V29y
ZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTEsMDtUcmFuc3Bvcn
RXcml0ZXJQcm9kdWNlciwyMCwyMg==
X-MS-Exchange-Forest-IndexAgent: 1 4678
X-MS-Exchange-Forest-EmailMessageHash: 06F33EE3
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
Thanks for the clarification, looks good.
On 2024/3/29 19:23, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-30 10:19 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-03-30 10:19 UTC (permalink / raw)
To: Conor Dooley
Cc: Stefan O'Rear, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Thanks for the clarification, looks good.
On 2024/3/29 19:23, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
>
X-sender: <netdev+bounces-83499-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com NOTIFY=NEVER; X-ExtendedProps=BQAVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ==
X-CreatedBy: MSExchange15
X-HeloDomain: b.mx.secunet.com
X-ExtendedProps: BQBjAAoAU4mmlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAGQAAADZigAABQBkAA8AAwAAAEh1Yg==
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.37
X-EndOfInjectedXHeaders: 21009
Received: from cas-essen-02.secunet.de (10.53.40.202) by
mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.2507.37; Sat, 30 Mar 2024 11:19:50 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
(10.53.40.202) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
Transport; Sat, 30 Mar 2024 11:19:50 +0100
Received: from localhost (localhost [127.0.0.1])
by b.mx.secunet.com (Postfix) with ESMTP id DA4E3202BE
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 11:19:50 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level:
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=2.1
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=unavailable autolearn_force=no
Received: from b.mx.secunet.com ([127.0.0.1])
by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 19NrXs2x69LU for <steffen.klassert@secunet.com>;
Sat, 30 Mar 2024 11:19:49 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=147.75.80.249; helo=am.mirrors.kernel.org; envelope-from=netdev+bounces-83499-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com D53502025D
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by b.mx.secunet.com (Postfix) with ESMTPS id D53502025D
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 11:19:49 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 5FB3D1F22438
for <steffen.klassert@secunet.com>; Sat, 30 Mar 2024 10:19:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8F26528DDF;
Sat, 30 Mar 2024 10:19:41 +0000 (UTC)
X-Original-To: netdev@vger.kernel.org
Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AE2C11712;
Sat, 30 Mar 2024 10:19:38 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.51
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1711793981; cv=none; b=XjBCD05gp0RzPexcO+ruoj3Fvp0FHXH+g1yfSbBCSauFIO1tUJvCAj18ickaY2KtMh11GdCoGwv3yLyQZoDDBinyTfTzxZ5XaxHx7XGBoBo5iGdcqn7ARJxFLji2YUWRwxjWGn6aW3Oinox5cToQXAPElCFyZ7MFApmpor1VULY=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1711793981; c=relaxed/simple;
bh=Kj8wuHAHZVd+Kvn7QFiN9E4M/87APJxMIBq/ikHQ35Y=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=ilzO63a9w9glrMWlidF2JyKlGjQXsTBHUwYWqKLjURwPleSvCK0pu0qEQdVpkPgBj5Tx3dxnOZS852pfce8pAD873pPxN2FP6XW++Ruqeqw5s1oHFlXc5dC6RReHxltRJkkBQ+ajCbNKwPRUITLQoWw6vma09F/1Pl3fF0oK81s=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.51
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com
Received: from mail.maildlp.com (unknown [172.19.163.235])
by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4V6Ctd17Lrz4f3lgL;
Sat, 30 Mar 2024 18:19:21 +0800 (CST)
Received: from mail02.huawei.com (unknown [10.116.40.75])
by mail.maildlp.com (Postfix) with ESMTP id 64B191A0568;
Sat, 30 Mar 2024 18:19:29 +0800 (CST)
Received: from [10.67.109.184] (unknown [10.67.109.184])
by APP2 (Coremail) with SMTP id Syh0CgCXug0s5wdmXWTTIg--.19989S2;
Sat, 30 Mar 2024 18:19:25 +0800 (CST)
Message-ID: <95e1978f-341c-4de5-a665-e057fe97a060@huaweicloud.com>
Date: Sat, 30 Mar 2024 18:19:24 +0800
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb
instructions
Content-Language: en-US
To: Conor Dooley <conor@kernel.org>
CC: Stefan O'Rear <sorear@fastmail.com>, <bpf@vger.kernel.org>,
<linux-riscv@lists.infradead.org>, <netdev@vger.kernel.org>,
=?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= <bjorn@kernel.org>, Alexei Starovoitov
<ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko
<andrii@kernel.org>, Martin KaFai Lau <martin.lau@linux.dev>, Eduard
Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>, Yonghong Song
<yhs@fb.com>, John Fastabend <john.fastabend@gmail.com>, KP Singh
<kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>, Hao Luo
<haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>, Mykola Lysenko
<mykolal@fb.com>, Manu Bretelle <chantr4@gmail.com>, Pu Lehui
<pulehui@huawei.com>
References: <20240328124916.293173-1-pulehui@huaweicloud.com>
<20240328124916.293173-3-pulehui@huaweicloud.com>
<3ed9fe94-2610-41eb-8a00-a9f37fcf2b1a@app.fastmail.com>
<20240328-ferocity-repose-c554f75a676c@spud>
<20240329-linguini-uncured-380cb4cff61c@wendy>
From: Pu Lehui <pulehui@huaweicloud.com>
In-Reply-To: <20240329-linguini-uncured-380cb4cff61c@wendy>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-CM-TRANSID: Syh0CgCXug0s5wdmXWTTIg--.19989S2
X-Coremail-Antispam: 1UD129KBjvJXoWxur4UGFW5XF4UXrWDGFW5GFg_yoWrtF4DpF
WfKF1xKFn7Jw1fZ393Xw18Wr1093Z7Kw43GrykG34Fy343ur1xGw1qy3ZrXFyDZrn3Gr1a
v390gF1q93WUCFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2
9KBjDU0xBIdaVrnRJUUUkYb4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2
6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4
vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj
xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x
0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG
6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV
Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7MxAIw28IcxkI
7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxV
Cjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY
6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6x
AIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280
aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7IUbG2NtUUUUU==
X-CM-SenderInfo: psxovxtxl6x35dzhxuhorxvhhfrp/
Return-Path: netdev+bounces-83499-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 30 Mar 2024 10:19:50.9305
(UTC)
X-MS-Exchange-Organization-Network-Message-Id: 922a0c38-9365-43f6-727c-08dc50a2ef4a
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=mbx-essen-02.secunet.de:TOTAL-HUB=0.192|SMR=0.113(SMRDE=0.003|SMRC=0.109(SMRCL=0.108|X-SMRCR=0.065))|CAT=0.078(CATOS=0.001
|CATRESL=0.027(CATRESLP2R=0.021)|CATORES=0.047(CATRS=0.047(CATRS-Transport
Rule Agent=0.001 (X-ETREX=0.001)|CATRS-Index Routing
Agent=0.045)));2024-03-30T10:19:51.131Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 12913
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRV=cas-essen-02.secunet.de:TOTAL-FE=0.008|SMR=0.008(SMRPI=0.006(SMRPI-FrontendProxyAgent=0.006))
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAUILAAAPAAADH4sIAAAAAAAEAN1Ya2/byBUdWbJsS34lu9
lF+2mQL9ndSLIsP2MUiziOtxG6fsB2vdgUhUGRI4s1xeHy4UT/oz+4
Z+4lKdKPJC26QFFBkYfDO/dx7rl3ZvLP7y9Gln8TyaEOZTxS0vas0B
26thW72m9JT2u8vNba6Sw1lhonvux1e5trG2u9V3L91V5voyUPtI+1
b7X21ER+CHWs9pYaP0qIXoySljyyQtnbbdE6acVyvbvX3cHC0yP5so
vPYwrw/VHuR7IvI8t1pPZl/+xAxlpOdCKVFXquClt4G49c/4Zc/4ut
/aF7LXVgfI/kSIVKWvjn+qTMVwp6htKSAzfmQRSErn+NoJXlm0HbKJ
rIaKQTz5EDJcfaARpYB8PqY+BZqS6IuSEUO+6t6ySWJ4MkDHSkopZZ
FY8QqPKtgWeUGn/GbmSxV65Pzt6o0Fce6ULwA2UEQ/Vb4oYwZpKRRC
qMAstWHdl/4XkyDifGiUj5DhwPrNgepUmDLXdImvpQMVbjgcK0Husw
1B86DKU812NloLqWnntjPHSjFGXZbssfd/FrxrYejwHO1npva6u7OV
CWcpzt7VeD7m5vMNzZHHR73e6GtbOzsd3d3ukaq3I/iUc63Cun8U+2
eeo49PR67Nqhtkdu0IF+svnWQpallD+FLjMEdFrfW9/Y6/WYKcSN1E
H6nPXPD9qXeylBQRQTd4So6M3lVf98/wd5hwGOLmp4m1CyaY3jRnYS
RZDKmDVRUaxCx5pIyye6nSYvIjkIhinWf1v/e66pL30du7ahhfEC+Y
xKbtxloiEhViA7ludNiG5hrswa6CTOCDUOvLT2og6A8SeGp6w/p7V1
a7QZWcuOjacGilxdzhvpwrDn6Q/MXke3iC/qowUjKAxfWkFuTdp4xl
L5fjDIVYXq2godT0WR8eLDCAQCs6DDxDIlMVQreHuARnKtaH6kvEDG
6iOkdK7NENhAO01gSR/sc4TSGg6VHUfyH0lUNNOC5BQ0L9LFEjnWvr
oPFfBJGHHtx6H27tvMFcJZ5RMfAJujYngA3JyJb4G8pMOKKNsvDK1g
rAxOmvFcXepBC2yTTqgDaVLJiFC9mjyriKJLo4bZYv3nmlIXUp+oKY
fqgw4dw2WsHxvHnjtafjTR+XJSDOB5p1gAP6NT7slRHAfR3tqap0PV
YWg7OrxeQ69KPrZDFMbtminB7kZvtz1UKFw3nrRDZdpb297a2hzubF
nbO9v26yhInLVSYZy7175y2no4bA8m/2ZLoE+b21BaZY7rUKeSAytS
VJQxoATc59Y4UR5SYRPpIsI4SBGRR0d/LXD4tyQxXdHPGOUaskcKjR
pl1zfJfBFPd5FQQatFjQS1Ee/lir4Ytl5vBz1ye6Pbwc/m1sZGe7Md
kb+dkfY8lMDrCHvKrTKRr6X5wS4zRPDX6L3WmhXaozXWmHWSwQOTZh
12IPVROrtoyTvDrVew3ukMN3o71q5lb2/uDrHddrc3N7nNtx/Ubd69
fPnyUROvX8v2Vne9tStf8h9MpF7lLe/q/PJ4//TkIkcLDAywU0UmZy
y1//PF4dnx/kX/8rAoNbQSL5aT6ZTpHeRu+rxvWljWaUwfI2pTns9v
fStAGcOB9rR+SzUby4HWcVEf9mJFfYj2Z3RJ8CKJrGvVISAyq44joy
QIdBjnR6OHzVHRIW3FtjGYFHUVOmXqT6kq8bkoaC81oiTi5j22whtq
Yu51opNInl4cRqbuLRka/hd1oToKgrduaFpgO9btYDSJDCxoxJYfee
lxxARnSd+Kk9Aglie81229QsLpz8MJP31z9Hvk20Af5dibhBfyWUh+
EKLT+3bW9YFfMBiXMn0nUd+dJ4EKb91Ih20c63D8CJD1NrcWnJq0OW
BNAhV9b+hRUvRJqjzCFePN5zwoqXnUm4cZVqZVSdNDFCOOFfSmiTdG
iS842HLfGw9cn48E5oQcx6GLPqmiki7ew3D4xeGBd3zbskfKGrge9o
qWdB01BpeRHjzQcSp0lDl85fTaXG+t45BHf7cKBLs4Ofn54N1+//jq
3f751eWD/MIL8/Lk9KJ/cny1f3bwLo/1Hk0vp3kEKp58fnl4cHFyVq
iyNHPPpwimggCajksPCd7z6Uv8/ul0ui3hHO8ZJr/99Xj/qH9wdd7/
809n+0dfVirZ5xyH1WO+5rhDuhd9sHyuGVw3DGNRNPKWAwkVSh7MCb
DtKgdbYpHhpUtJid3lN/IXF4d9Oq6CjenJhavDaeGC5dLpqsBMn08y
mbbp4XQM3815k727y9Y+h8N7842PDYCO+3SMpYBxsIKCX7N1hlO4kZ
g9aru788ge9f7Nm/+hfpV6M+0x0zaBJoADn7mkjnEtDRLu1d9/fte6
14q+5A7K/QXPJU24BzxyJn5kD6MGU14FquF2rIy9KA4Tm40DIsu2Qf
/QNA/sPYm5sJZUASJE344CZZv/i4D3RphWf2frBBw34AQ6gwZswMGT
LZtzcSvnRG/DbGPbvc1HtrH3/YM3J0f3ypIF3h7tXx2fHB+cvDs8Oz
y+uF+8eP+2f4aOcnV2eLR/+juQJHfvIZ4cmKYr33javjF3RbDBHHPl
SY7WXcqUFH3hTvbetQd6/HmzJUWPu0BF/wD/yvtbSdknCXfXO3OPHa
j84ITrAe5oxYtvSYWv/batTUPxKZ159OYcqW5xxedLH//fkUs+MLF2
N1s7INbuVqnZlFr8f62DDz0NMP3rdqBdP/6/7uTmPxmXGkLUxVxV1P
BdEiuzol4TCzOiWquIBXzFbEXMzFSqs0LMijm8rZvfBgSqYrZaEYv4
itqMqNXELMTmK2Je4Dt/b8kylkCVETNra/w7Z4zMQIbG8/hCgN7OsS
TesjAG0DMvmpjHADPz5OecWMTyhmjOk1d4i/klMoeFddHEAAKYxOMC
LWeFNQqNTZOtOTxCbF6sLogGZmqV1YoQCAjmvhOtupinWOax7I8UFM
SqxuF5g14FOsUUgcpCTYhaZZZAeAIw68ZclQPEd9ZgC9MmFkzOiOU6
hdwgh8nVRu4nBrOVOXKmCSdZCZzJlTB0nERG27wV9UWxzDBizKswZv
RqYmmBECPr1Rlay+OmWGRVVbHI/vB8rr9G4TNupLNZzZbnkmwoT2jd
zBvwOQW5SwC8vKrJXmEebrCSHJY5sTrH5CSdbJ0DzykBnzGzQHrIUC
0nnmGykfmmRtCdkG8cCMNF2V/AzKJYqmWA1ytiiWRmSOweAf7AFOWM
5LFzXMw6uGQUUtQ14hsTjxEg1j2Fzl/u+bMsVliAkaRXQG+ONbBFFs
jGTU76YmWpbup6ufBqZTquLDM5TYCVmemYrGP0JK3HJ5wXnmmKZ2QL
DqxyUXN2OO9Vg5IhLWcNMlneOZynqVjGk1yeYcnKeTlPZU18zZILWV
3zbyPjD2H4BAPMIFVfkatQAqgZn4XK6qfDXKUw64ZUD4b5hNnFFcGB
cM+hVV9lITQbFbFi5Ouw2iCEqQYhv5qF/1UxfDN5d+3TO2vLsFQzWF
Zq4llWg7M5DeapizLyDfEtz+AtmNAkNOYrKxw+96jpmGlsfGiQtmba
DSriaWYUjYLhaqbUbdYy8s/B7cKY197XViUNcwZwVMTTnEW5/xwgD/
JyptQ/y9HOBukeQQILuXBVrHDDpMdvWJj2stkcybT0KoufZsUSicHn
/4AVVbN3NHlPWczIfIcA5e2J87jKDT9PN2eZJ5nSzHNqBQQFbbt41a
DtD5IYmO5aefKFnOfHZ/SI6JiTq+n2sfJZ8nOYvPM2aL8gmdX7VC9I
fluQrOVngHqJ7c/y8LMGW8vLP+s2X+fh53tWvrHOVBqfQIDT+ln6QW
JZLHB3/V1I+C/a/EeECx4AAAEK4QE8P3htbCB2ZXJzaW9uPSIxLjAi
IGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxFbWFpbFNldD4NCiAgPFZlcn
Npb24+MTUuMC4wLjA8L1ZlcnNpb24+DQogIDxFbWFpbHM+DQogICAg
PEVtYWlsIFN0YXJ0SW5kZXg9IjU5OSI+DQogICAgICA8RW1haWxTdH
Jpbmc+Y29ub3IuZG9vbGV5QG1pY3JvY2hpcC5jb208L0VtYWlsU3Ry
aW5nPg0KICAgIDwvRW1haWw+DQogIDwvRW1haWxzPg0KPC9FbWFpbF
NldD4BC7wDPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRm
LTE2Ij8+DQo8VXJsU2V0Pg0KICA8VmVyc2lvbj4xNS4wLjAuMDwvVm
Vyc2lvbj4NCiAgPFVybHM+DQogICAgPFVybCBTdGFydEluZGV4PSIx
NTIxIiBUeXBlPSJVcmwiPg0KICAgICAgPFVybFN0cmluZz5odHRwcz
ovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi8yMDI0MDMyOC1m
ZXJvY2l0eS1yZXBvc2UtYzU1NGY3NWE2NzZjQHNwdWQvPC9VcmxTdH
Jpbmc+DQogICAgPC9Vcmw+DQogICAgPFVybCBTdGFydEluZGV4PSIx
ODMyIiBUeXBlPSJVcmwiPg0KICAgICAgPFVybFN0cmluZz5odHRwcz
ovL2xvcmUua2VybmVsLm9yZy9saW51eC1yaXNjdi8yMDI0MDIyNzAw
MzYzMC4zNjM0NTMzLTQtc2FtdWVsLmhvbGxhbmRAc2lmaXZlLmNvbS
88L1VybFN0cmluZz4NCiAgICA8L1VybD4NCiAgPC9VcmxzPg0KPC9V
cmxTZXQ+AQz9Bjw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9In
V0Zi0xNiI/Pg0KPENvbnRhY3RTZXQ+DQogIDxWZXJzaW9uPjE1LjAu
MC4wPC9WZXJzaW9uPg0KICA8Q29udGFjdHM+DQogICAgPENvbnRhY3
QgU3RhcnRJbmRleD0iNTg1Ij4NCiAgICAgIDxQZXJzb24gU3RhcnRJ
bmRleD0iNTg1Ij4NCiAgICAgICAgPFBlcnNvblN0cmluZz5Db25vci
BEb29sZXk8L1BlcnNvblN0cmluZz4NCiAgICAgIDwvUGVyc29uPg0K
ICAgICAgPEVtYWlscz4NCiAgICAgICAgPEVtYWlsIFN0YXJ0SW5kZX
g9IjU5OSI+DQogICAgICAgICAgPEVtYWlsU3RyaW5nPmNvbm9yLmRv
b2xleUBtaWNyb2NoaXAuY29tPC9FbWFpbFN0cmluZz4NCiAgICAgIC
AgPC9FbWFpbD4NCiAgICAgIDwvRW1haWxzPg0KICAgICAgPENvbnRh
Y3RTdHJpbmc+Q29ub3IgRG9vbGV5ICZsdDtjb25vci5kb29sZXlAbW
ljcm9jaGlwLmNvbTwvQ29udGFjdFN0cmluZz4NCiAgICA8L0NvbnRh
Y3Q+DQogICAgPENvbnRhY3QgU3RhcnRJbmRleD0iMTYyOCI+DQogIC
AgICA8UGVyc29uIFN0YXJ0SW5kZXg9IjE2MjgiPg0KICAgICAgICA8
UGVyc29uU3RyaW5nPkNvbm9yIERvb2xleTwvUGVyc29uU3RyaW5nPg
0KICAgICAgPC9QZXJzb24+DQogICAgICA8RW1haWxzPg0KICAgICAg
ICA8RW1haWwgU3RhcnRJbmRleD0iMTY0MiI+DQogICAgICAgICAgPE
VtYWlsU3RyaW5nPmNvbm9yLmRvb2xleUBtaWNyb2NoaXAuY29tPC9F
bWFpbFN0cmluZz4NCiAgICAgICAgPC9FbWFpbD4NCiAgICAgIDwvRW
1haWxzPg0KICAgICAgPENvbnRhY3RTdHJpbmc+Q29ub3IgRG9vbGV5
ICZsdDtjb25vci5kb29sZXlAbWljcm9jaGlwLmNvbTwvQ29udGFjdF
N0cmluZz4NCiAgICA8L0NvbnRhY3Q+DQogIDwvQ29udGFjdHM+DQo8
L0NvbnRhY3RTZXQ+AQ7PAVJldHJpZXZlck9wZXJhdG9yLDEwLDI7Um
V0cmlldmVyT3BlcmF0b3IsMTEsMjtQb3N0RG9jUGFyc2VyT3BlcmF0
b3IsMTAsMTtQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQb3N0V2
9yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTAsNTtQb3N0V29y
ZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTEsMDtUcmFuc3Bvcn
RXcml0ZXJQcm9kdWNlciwyMCwyMg==
X-MS-Exchange-Forest-IndexAgent: 1 4678
X-MS-Exchange-Forest-EmailMessageHash: 06F33EE3
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent
Thanks for the clarification, looks good.
On 2024/3/29 19:23, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
>
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-29 11:23 ` Conor Dooley
@ 2024-03-31 17:49 ` Samuel Holland
-1 siblings, 0 replies; 60+ messages in thread
From: Samuel Holland @ 2024-03-31 17:49 UTC (permalink / raw)
To: Conor Dooley, Conor Dooley
Cc: Stefan O'Rear, Pu Lehui, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Hi Conor,
Looks good except for one typo.
On 2024-03-29 6:23 AM, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
s/vector/floating point/ here.
Regards,
Samuel
>
> If you don't know what to do here, say Y.
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-03-31 17:49 ` Samuel Holland
0 siblings, 0 replies; 60+ messages in thread
From: Samuel Holland @ 2024-03-31 17:49 UTC (permalink / raw)
To: Conor Dooley, Conor Dooley
Cc: Stefan O'Rear, Pu Lehui, bpf, linux-riscv, netdev,
Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Hi Conor,
Looks good except for one typo.
On 2024-03-29 6:23 AM, Conor Dooley wrote:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
> + Zbb extension is detected at boot.
>
> The Zbb extension provides instructions to accelerate a number
> of bit-specific operations (count bit population, sign extending,
> @@ -623,9 +624,9 @@ config RISCV_ISA_ZICBOM
> select RISCV_DMA_NONCOHERENT
> select DMA_DIRECT_REMAP
> help
> - Adds support to dynamically detect the presence of the ZICBOM
> - extension (Cache Block Management Operations) and enable its
> - usage.
> + Add support for the Zicbom extension (Cache Block Management
> + Operations) and enable its use in the kernel when it is detected
> + at boot.
>
> The Zicbom extension can be used to handle for example
> non-coherent DMA support on devices that need it.
> @@ -684,7 +685,8 @@ config FPU
> default y
> help
> Say N here if you want to disable all floating-point related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
s/vector/floating point/ here.
Regards,
Samuel
>
> If you don't know what to do here, say Y.
>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-29 11:23 ` Conor Dooley
@ 2024-04-02 14:18 ` Björn Töpel
-1 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 14:18 UTC (permalink / raw)
To: Conor Dooley, Conor Dooley
Cc: Stefan O'Rear, Pu Lehui, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
Conor Dooley <conor.dooley@microchip.com> writes:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
I don't care much, but "optimizations" here -- for consistency reasons!
[1] ;-)
Nice change!
Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
[1] https://lwn.net/Articles/636286/
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-02 14:18 ` Björn Töpel
0 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 14:18 UTC (permalink / raw)
To: Conor Dooley, Conor Dooley
Cc: Stefan O'Rear, Pu Lehui, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
Conor Dooley <conor.dooley@microchip.com> writes:
> On Thu, Mar 28, 2024 at 10:07:23PM +0000, Conor Dooley wrote:
>
>> As I said on IRC to you earlier, I think the Kconfig options here are in
>> need of a bit of a spring cleaning - they should be modified to explain
>> their individual purposes, be that enabling optimisations in the kernel
>> or being required for userspace. I'll try to send a patch for that if
>> I remember tomorrow.
>
> Something like this:
>
> -- >8 --
> commit 5125504beaedd669b082bf74b02003a77360670f
> Author: Conor Dooley <conor.dooley@microchip.com>
> Date: Fri Mar 29 11:13:22 2024 +0000
>
> RISC-V: clarify what some RISCV_ISA* config options do
>
> During some discussion on IRC yesterday and on Pu's bpf patch [1]
> I noticed that these RISCV_ISA* Kconfig options are not really clear
> about their implications. Many of these options have no impact on what
> userspace is allowed to do, for example an application can use Zbb
> regardless of whether or not the kernel does. Change the help text to
> try and clarify whether or not an option affects just the kernel, or
> also userspace. None of these options actually control whether or not an
> extension is detected dynamically as that's done regardless of Kconfig
> options, so drop any text that implies the option is required for
> dynamic detection, rewording them as "do x when y is detected".
>
> Link: https://lore.kernel.org/linux-riscv/20240328-ferocity-repose-c554f75a676c@spud/ [1]
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> I did this based on top of Samuel's changes dropping the MMU
> requurements just in case, but I don't think there's a conflict:
> https://lore.kernel.org/linux-riscv/20240227003630.3634533-4-samuel.holland@sifive.com/
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d8a777f59402..f327a8ac648f 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -501,8 +501,8 @@ config RISCV_ISA_SVNAPOT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Allow kernel to detect the Svnapot ISA-extension dynamically at boot
> - time and enable its usage.
> + Add support for the Svnapot ISA-extension when it is detected by
> + the kernel at boot.
>
> The Svnapot extension is used to mark contiguous PTEs as a range
> of contiguous virtual-to-physical translations for a naturally
> @@ -520,9 +520,9 @@ config RISCV_ISA_SVPBMT
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the Svpbmt
> - ISA-extension (Supervisor-mode: page-based memory types) and
> - enable its usage.
> + Add support for the Svpbmt ISA-extension (Supervisor-mode:
> + page-based memory types) when it is detected by the kernel at
> + boot.
>
> The memory type for a page contains a combination of attributes
> that indicate the cacheability, idempotency, and ordering
> @@ -541,14 +541,15 @@ config TOOLCHAIN_HAS_V
> depends on AS_HAS_OPTION_ARCH
>
> config RISCV_ISA_V
> - bool "VECTOR extension support"
> + bool "Vector extension support"
> depends on TOOLCHAIN_HAS_V
> depends on FPU
> select DYNAMIC_SIGFRAME
> default y
> help
> Say N here if you want to disable all vector related procedure
> - in the kernel.
> + in the kernel. Without this option enabled, neither the kernel nor
> + userspace may use vector.
>
> If you don't know what to do here, say Y.
>
> @@ -606,8 +607,8 @@ config RISCV_ISA_ZBB
> depends on RISCV_ALTERNATIVE
> default y
> help
> - Adds support to dynamically detect the presence of the ZBB
> - extension (basic bit manipulation) and enable its usage.
> + Add support for enabling optimisations in the kernel when the
I don't care much, but "optimizations" here -- for consistency reasons!
[1] ;-)
Nice change!
Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
[1] https://lwn.net/Articles/636286/
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-29 10:05 ` Pu Lehui
@ 2024-04-02 14:25 ` Björn Töpel
-1 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 14:25 UTC (permalink / raw)
To: Pu Lehui, Stefan O'Rear, Conor Dooley
Cc: bpf, linux-riscv, netdev, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Pu Lehui <pulehui@huaweicloud.com> writes:
> On 2024/3/29 6:07, Conor Dooley wrote:
>> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>
>>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>>>> is capable of recognizing the Zbb instructions independently, eliminating
>>>> the need for reliance on kernel compile configurations.
>>>
>>> This doesn't make sense to me.
>>
>> It doesn't make sense to me either. Of course the hardware's capability
>> to understand an instruction is independent of whether or not a
>> toolchain is capable of actually emitting the instruction.
>>
>>> RISCV_ISA_ZBB is defined as:
>>>
>>> Adds support to dynamically detect the presence of the ZBB
>>> extension (basic bit manipulation) and enable its usage.
>>>
>>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>>> checks can be constant-folded.
>
> Thanks for review. My initial thought was the same as yours, but after
> discussions [0] and test verifications, the hardware can indeed
> recognize the zbb instruction even if the kernel has not enabled
> CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
> emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
I still think Lehui's patch is correct; Building a kernel that can boot
on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
the kernel proper, and iff Zbb is available at run-time the BPF JIT will
emit Zbb.
For these kind of optimizations, (IMO) it's better to let the BPF JIT
decide at run-time.
Björn
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-02 14:25 ` Björn Töpel
0 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 14:25 UTC (permalink / raw)
To: Pu Lehui, Stefan O'Rear, Conor Dooley
Cc: bpf, linux-riscv, netdev, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Jiri Olsa, Mykola Lysenko, Manu Bretelle, Pu Lehui
Pu Lehui <pulehui@huaweicloud.com> writes:
> On 2024/3/29 6:07, Conor Dooley wrote:
>> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>>>> From: Pu Lehui <pulehui@huawei.com>
>>>>
>>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>>>> is capable of recognizing the Zbb instructions independently, eliminating
>>>> the need for reliance on kernel compile configurations.
>>>
>>> This doesn't make sense to me.
>>
>> It doesn't make sense to me either. Of course the hardware's capability
>> to understand an instruction is independent of whether or not a
>> toolchain is capable of actually emitting the instruction.
>>
>>> RISCV_ISA_ZBB is defined as:
>>>
>>> Adds support to dynamically detect the presence of the ZBB
>>> extension (basic bit manipulation) and enable its usage.
>>>
>>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>>> checks can be constant-folded.
>
> Thanks for review. My initial thought was the same as yours, but after
> discussions [0] and test verifications, the hardware can indeed
> recognize the zbb instruction even if the kernel has not enabled
> CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
> emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
I still think Lehui's patch is correct; Building a kernel that can boot
on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
the kernel proper, and iff Zbb is available at run-time the BPF JIT will
emit Zbb.
For these kind of optimizations, (IMO) it's better to let the BPF JIT
decide at run-time.
Björn
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-03-28 12:49 ` Pu Lehui
@ 2024-04-02 14:27 ` Björn Töpel
-1 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 14:27 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui, Pu Lehui
Pu Lehui <pulehui@huaweicloud.com> writes:
> From: Pu Lehui <pulehui@huawei.com>
>
> This patch relaxes the restrictions on the Zbb instructions. The hardware
> is capable of recognizing the Zbb instructions independently, eliminating
> the need for reliance on kernel compile configurations.
>
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
Should this patch really be part of this series?
Björn
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-02 14:27 ` Björn Töpel
0 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 14:27 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui, Pu Lehui
Pu Lehui <pulehui@huaweicloud.com> writes:
> From: Pu Lehui <pulehui@huawei.com>
>
> This patch relaxes the restrictions on the Zbb instructions. The hardware
> is capable of recognizing the Zbb instructions independently, eliminating
> the need for reliance on kernel compile configurations.
>
> Signed-off-by: Pu Lehui <pulehui@huawei.com>
Should this patch really be part of this series?
Björn
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-02 14:27 ` Björn Töpel
@ 2024-04-02 16:03 ` Daniel Borkmann
-1 siblings, 0 replies; 60+ messages in thread
From: Daniel Borkmann @ 2024-04-02 16:03 UTC (permalink / raw)
To: Björn Töpel, Pu Lehui, bpf, linux-riscv, netdev
Cc: Alexei Starovoitov, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 4/2/24 4:27 PM, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
>> From: Pu Lehui <pulehui@huawei.com>
>>
>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>> is capable of recognizing the Zbb instructions independently, eliminating
>> the need for reliance on kernel compile configurations.
>>
>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>
> Should this patch really be part of this series?
No, that should be submitted independently.
Also, given Eduard's comment, it would be great if you could add the
instructions to tools/testing/selftests/bpf/README.rst even if not in
a perfect shape, but it would give developers a chance to get started.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-02 16:03 ` Daniel Borkmann
0 siblings, 0 replies; 60+ messages in thread
From: Daniel Borkmann @ 2024-04-02 16:03 UTC (permalink / raw)
To: Björn Töpel, Pu Lehui, bpf, linux-riscv, netdev
Cc: Alexei Starovoitov, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 4/2/24 4:27 PM, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
>> From: Pu Lehui <pulehui@huawei.com>
>>
>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>> is capable of recognizing the Zbb instructions independently, eliminating
>> the need for reliance on kernel compile configurations.
>>
>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>
> Should this patch really be part of this series?
No, that should be submitted independently.
Also, given Eduard's comment, it would be great if you could add the
instructions to tools/testing/selftests/bpf/README.rst even if not in
a perfect shape, but it would give developers a chance to get started.
Thanks,
Daniel
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-02 14:25 ` Björn Töpel
@ 2024-04-02 17:38 ` Conor Dooley
-1 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-04-02 17:38 UTC (permalink / raw)
To: Björn Töpel
Cc: Pu Lehui, Stefan O'Rear, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1: Type: text/plain, Size: 3304 bytes --]
On Tue, Apr 02, 2024 at 04:25:24PM +0200, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
>
> > On 2024/3/29 6:07, Conor Dooley wrote:
> >> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
> >>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
> >>>> From: Pu Lehui <pulehui@huawei.com>
> >>>>
> >>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
> >>>> is capable of recognizing the Zbb instructions independently, eliminating
> >>>> the need for reliance on kernel compile configurations.
> >>>
> >>> This doesn't make sense to me.
> >>
> >> It doesn't make sense to me either. Of course the hardware's capability
> >> to understand an instruction is independent of whether or not a
> >> toolchain is capable of actually emitting the instruction.
> >>
> >>> RISCV_ISA_ZBB is defined as:
> >>>
> >>> Adds support to dynamically detect the presence of the ZBB
> >>> extension (basic bit manipulation) and enable its usage.
> >>>
> >>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
> >>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
> >>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
> >>> checks can be constant-folded.
> >
> > Thanks for review. My initial thought was the same as yours, but after
> > discussions [0] and test verifications, the hardware can indeed
> > recognize the zbb instruction even if the kernel has not enabled
> > CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
> > emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
>
> I still think Lehui's patch is correct; Building a kernel that can boot
> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
> emit Zbb.
This sentence is -ENOPARSE to me, did you accidentally omit some words?
Additionally he config option has nothing to do with building kernels that
boot on multiple platforms, it only controls whether optimisations for Zbb
are built so that if Zbb is detected they can be used.
> For these kind of optimizations, (IMO) it's better to let the BPF JIT
> decide at run-time.
Why is bpf a different case to any other user in this regard?
I think that the commit message is misleading and needs to be changed,
because the point "the hardware is capable of recognising the Zbb
instructions independently..." is completely unrelated to the purpose
of the config option. Of course the hardware understanding the option
has nothing to do with kernel configuration. The commit message needs to
explain why bpf is a special case and is exempt from an
I totally understand any point about bpf being different in terms of
needing toolchain support, but IIRC it was I who pointed out up-thread.
The part of the conversation that you're replying to here is about the
semantics of the Kconfig option and the original patch never mentioned
trying to avoid a dependency on toolchains at all, just kernel
configurations. The toolchain requirements I don't think are even super
hard to fulfill either - the last 3 versions of ld and lld all meet the
criteria.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-02 17:38 ` Conor Dooley
0 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-04-02 17:38 UTC (permalink / raw)
To: Björn Töpel
Cc: Pu Lehui, Stefan O'Rear, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1.1: Type: text/plain, Size: 3304 bytes --]
On Tue, Apr 02, 2024 at 04:25:24PM +0200, Björn Töpel wrote:
> Pu Lehui <pulehui@huaweicloud.com> writes:
>
> > On 2024/3/29 6:07, Conor Dooley wrote:
> >> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
> >>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
> >>>> From: Pu Lehui <pulehui@huawei.com>
> >>>>
> >>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
> >>>> is capable of recognizing the Zbb instructions independently, eliminating
> >>>> the need for reliance on kernel compile configurations.
> >>>
> >>> This doesn't make sense to me.
> >>
> >> It doesn't make sense to me either. Of course the hardware's capability
> >> to understand an instruction is independent of whether or not a
> >> toolchain is capable of actually emitting the instruction.
> >>
> >>> RISCV_ISA_ZBB is defined as:
> >>>
> >>> Adds support to dynamically detect the presence of the ZBB
> >>> extension (basic bit manipulation) and enable its usage.
> >>>
> >>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
> >>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
> >>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
> >>> checks can be constant-folded.
> >
> > Thanks for review. My initial thought was the same as yours, but after
> > discussions [0] and test verifications, the hardware can indeed
> > recognize the zbb instruction even if the kernel has not enabled
> > CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
> > emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
>
> I still think Lehui's patch is correct; Building a kernel that can boot
> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
> emit Zbb.
This sentence is -ENOPARSE to me, did you accidentally omit some words?
Additionally he config option has nothing to do with building kernels that
boot on multiple platforms, it only controls whether optimisations for Zbb
are built so that if Zbb is detected they can be used.
> For these kind of optimizations, (IMO) it's better to let the BPF JIT
> decide at run-time.
Why is bpf a different case to any other user in this regard?
I think that the commit message is misleading and needs to be changed,
because the point "the hardware is capable of recognising the Zbb
instructions independently..." is completely unrelated to the purpose
of the config option. Of course the hardware understanding the option
has nothing to do with kernel configuration. The commit message needs to
explain why bpf is a special case and is exempt from an
I totally understand any point about bpf being different in terms of
needing toolchain support, but IIRC it was I who pointed out up-thread.
The part of the conversation that you're replying to here is about the
semantics of the Kconfig option and the original patch never mentioned
trying to avoid a dependency on toolchains at all, just kernel
configurations. The toolchain requirements I don't think are even super
hard to fulfill either - the last 3 versions of ld and lld all meet the
criteria.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-02 17:38 ` Conor Dooley
@ 2024-04-02 19:00 ` Björn Töpel
-1 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 19:00 UTC (permalink / raw)
To: Conor Dooley
Cc: Pu Lehui, Stefan O'Rear, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
Hey Conor!
Conor Dooley <conor@kernel.org> writes:
> On Tue, Apr 02, 2024 at 04:25:24PM +0200, Björn Töpel wrote:
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>
>> > On 2024/3/29 6:07, Conor Dooley wrote:
>> >> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>> >>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>> >>>> From: Pu Lehui <pulehui@huawei.com>
>> >>>>
>> >>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>> >>>> is capable of recognizing the Zbb instructions independently, eliminating
>> >>>> the need for reliance on kernel compile configurations.
>> >>>
>> >>> This doesn't make sense to me.
>> >>
>> >> It doesn't make sense to me either. Of course the hardware's capability
>> >> to understand an instruction is independent of whether or not a
>> >> toolchain is capable of actually emitting the instruction.
>> >>
>> >>> RISCV_ISA_ZBB is defined as:
>> >>>
>> >>> Adds support to dynamically detect the presence of the ZBB
>> >>> extension (basic bit manipulation) and enable its usage.
>> >>>
>> >>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>> >>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>> >>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>> >>> checks can be constant-folded.
>> >
>> > Thanks for review. My initial thought was the same as yours, but after
>> > discussions [0] and test verifications, the hardware can indeed
>> > recognize the zbb instruction even if the kernel has not enabled
>> > CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
>> > emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
>>
>> I still think Lehui's patch is correct; Building a kernel that can boot
>> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
>> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
>> emit Zbb.
>
> This sentence is -ENOPARSE to me, did you accidentally omit some words?
> Additionally he config option has nothing to do with building kernels that
> boot on multiple platforms, it only controls whether optimisations for Zbb
> are built so that if Zbb is detected they can be used.
Ugh, sorry about that! I'm probably confused myself.
>> For these kind of optimizations, (IMO) it's better to let the BPF JIT
>> decide at run-time.
>
> Why is bpf a different case to any other user in this regard?
> I think that the commit message is misleading and needs to be changed,
> because the point "the hardware is capable of recognising the Zbb
> instructions independently..." is completely unrelated to the purpose
> of the config option. Of course the hardware understanding the option
> has nothing to do with kernel configuration. The commit message needs to
> explain why bpf is a special case and is exempt from an
>
> I totally understand any point about bpf being different in terms of
> needing toolchain support, but IIRC it was I who pointed out up-thread.
> The part of the conversation that you're replying to here is about the
> semantics of the Kconfig option and the original patch never mentioned
> trying to avoid a dependency on toolchains at all, just kernel
> configurations. The toolchain requirements I don't think are even super
> hard to fulfill either - the last 3 versions of ld and lld all meet the
> criteria.
Thanks for making it more clear, and I agree that the toolchain
requirements are not hard to fulfull.
My view has been that "BPF is like userland", but I realize now that's
odd. Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
the BPF JIT doesn't know about emitting Zbb.
Björn
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-02 19:00 ` Björn Töpel
0 siblings, 0 replies; 60+ messages in thread
From: Björn Töpel @ 2024-04-02 19:00 UTC (permalink / raw)
To: Conor Dooley
Cc: Pu Lehui, Stefan O'Rear, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
Hey Conor!
Conor Dooley <conor@kernel.org> writes:
> On Tue, Apr 02, 2024 at 04:25:24PM +0200, Björn Töpel wrote:
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>
>> > On 2024/3/29 6:07, Conor Dooley wrote:
>> >> On Thu, Mar 28, 2024 at 03:34:31PM -0400, Stefan O'Rear wrote:
>> >>> On Thu, Mar 28, 2024, at 8:49 AM, Pu Lehui wrote:
>> >>>> From: Pu Lehui <pulehui@huawei.com>
>> >>>>
>> >>>> This patch relaxes the restrictions on the Zbb instructions. The hardware
>> >>>> is capable of recognizing the Zbb instructions independently, eliminating
>> >>>> the need for reliance on kernel compile configurations.
>> >>>
>> >>> This doesn't make sense to me.
>> >>
>> >> It doesn't make sense to me either. Of course the hardware's capability
>> >> to understand an instruction is independent of whether or not a
>> >> toolchain is capable of actually emitting the instruction.
>> >>
>> >>> RISCV_ISA_ZBB is defined as:
>> >>>
>> >>> Adds support to dynamically detect the presence of the ZBB
>> >>> extension (basic bit manipulation) and enable its usage.
>> >>>
>> >>> In other words, RISCV_ISA_ZBB=n should disable everything that attempts
>> >>> to detect Zbb at runtime. It is mostly relevant for code size reduction,
>> >>> which is relevant for BPF since if RISCV_ISA_ZBB=n all rvzbb_enabled()
>> >>> checks can be constant-folded.
>> >
>> > Thanks for review. My initial thought was the same as yours, but after
>> > discussions [0] and test verifications, the hardware can indeed
>> > recognize the zbb instruction even if the kernel has not enabled
>> > CONFIG_RISCV_ISA_ZBB. As Conor mentioned, we are just acting as a JIT to
>> > emit zbb instruction here. Maybe is_hw_zbb_capable() will be better?
>>
>> I still think Lehui's patch is correct; Building a kernel that can boot
>> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
>> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
>> emit Zbb.
>
> This sentence is -ENOPARSE to me, did you accidentally omit some words?
> Additionally he config option has nothing to do with building kernels that
> boot on multiple platforms, it only controls whether optimisations for Zbb
> are built so that if Zbb is detected they can be used.
Ugh, sorry about that! I'm probably confused myself.
>> For these kind of optimizations, (IMO) it's better to let the BPF JIT
>> decide at run-time.
>
> Why is bpf a different case to any other user in this regard?
> I think that the commit message is misleading and needs to be changed,
> because the point "the hardware is capable of recognising the Zbb
> instructions independently..." is completely unrelated to the purpose
> of the config option. Of course the hardware understanding the option
> has nothing to do with kernel configuration. The commit message needs to
> explain why bpf is a special case and is exempt from an
>
> I totally understand any point about bpf being different in terms of
> needing toolchain support, but IIRC it was I who pointed out up-thread.
> The part of the conversation that you're replying to here is about the
> semantics of the Kconfig option and the original patch never mentioned
> trying to avoid a dependency on toolchains at all, just kernel
> configurations. The toolchain requirements I don't think are even super
> hard to fulfill either - the last 3 versions of ld and lld all meet the
> criteria.
Thanks for making it more clear, and I agree that the toolchain
requirements are not hard to fulfull.
My view has been that "BPF is like userland", but I realize now that's
odd. Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
the BPF JIT doesn't know about emitting Zbb.
Björn
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
2024-03-30 10:12 ` Pu Lehui
@ 2024-04-02 23:40 ` Eduard Zingerman
-1 siblings, 0 replies; 60+ messages in thread
From: Eduard Zingerman @ 2024-04-02 23:40 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On Sat, 2024-03-30 at 18:12 +0800, Pu Lehui wrote:
[...]
> > Looks like I won't be able to test this patch-set, unless you have
> > some writeup on how to create a riscv64 dev environment at hand.
> > Sorry for the noise
>
> Yeah, environmental issues are indeed a developer's nightmare. I will
> try to do something for the newcomers of riscv64 bpf. At present, I have
> simply built a docker local vmtest environment [0] based on Bjorn's
> riscv-cross-builder. We can directly run vmtest within this environment.
> Hopefully it will help.
>
> Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
Hi Pu,
Thank you for sharing the docker file, I've managed to run the tests
using it. In order to avoid creating files with root permissions I had
to add the following lines at the end of the Dockerfile:
+ RUN useradd --no-create-home --uid 1000 eddy
+ RUN passwd -d eddy
+ RUN echo 'eddy ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
+ # vmtest.sh does 'mount -o loop',
+ # ensure there is a loop device in the container
+ RUN mknod /dev/loop0 b 7 20
Where 'eddy' is my local user with UID 1000.
Probably this should be made more generic.
I used the following command to start the container:
docker run -ti -u 1000:1000 \
--rm -v <path-to-kernel-dir>:/workspace \
-v <path-to-rootfs-image-dir>:/rootfs \
--privileged ubuntu-vmtest:latest /bin/bash
Also, I had to add '-d /rootfs/bpf_selftests' option for vmtest.sh in
order to avoid polluting user directory inside the container.
Maybe OUTPUT_DIR for vmtest.sh should be mounted as a separate volume.
I agree with Daniel, it would be great to document all of this
somewhere in the repo (or even scripted somehow).
Using the specified DENYLIST I get the following stats for test_progs:
#3/2 arena_htab/arena_htab_asm:FAIL
#3 arena_htab:FAIL
#95 get_branch_snapshot:FAIL
#172/1 perf_branches/perf_branches_hw:FAIL
#172 perf_branches:FAIL
#434/3 verifier_arena/basic_alloc3:FAIL
#434 verifier_arena:FAIL
Summary: 531/3581 PASSED, 64 SKIPPED, 4 FAILED
Tested-by: Eduard Zingerman <eddyz87@gmail.com>
> PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
> modified vmtest.sh to support local rootfs.
Could you please add this change to the patch-set?
[...]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-04-02 23:40 ` Eduard Zingerman
0 siblings, 0 replies; 60+ messages in thread
From: Eduard Zingerman @ 2024-04-02 23:40 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
On Sat, 2024-03-30 at 18:12 +0800, Pu Lehui wrote:
[...]
> > Looks like I won't be able to test this patch-set, unless you have
> > some writeup on how to create a riscv64 dev environment at hand.
> > Sorry for the noise
>
> Yeah, environmental issues are indeed a developer's nightmare. I will
> try to do something for the newcomers of riscv64 bpf. At present, I have
> simply built a docker local vmtest environment [0] based on Bjorn's
> riscv-cross-builder. We can directly run vmtest within this environment.
> Hopefully it will help.
>
> Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
Hi Pu,
Thank you for sharing the docker file, I've managed to run the tests
using it. In order to avoid creating files with root permissions I had
to add the following lines at the end of the Dockerfile:
+ RUN useradd --no-create-home --uid 1000 eddy
+ RUN passwd -d eddy
+ RUN echo 'eddy ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
+ # vmtest.sh does 'mount -o loop',
+ # ensure there is a loop device in the container
+ RUN mknod /dev/loop0 b 7 20
Where 'eddy' is my local user with UID 1000.
Probably this should be made more generic.
I used the following command to start the container:
docker run -ti -u 1000:1000 \
--rm -v <path-to-kernel-dir>:/workspace \
-v <path-to-rootfs-image-dir>:/rootfs \
--privileged ubuntu-vmtest:latest /bin/bash
Also, I had to add '-d /rootfs/bpf_selftests' option for vmtest.sh in
order to avoid polluting user directory inside the container.
Maybe OUTPUT_DIR for vmtest.sh should be mounted as a separate volume.
I agree with Daniel, it would be great to document all of this
somewhere in the repo (or even scripted somehow).
Using the specified DENYLIST I get the following stats for test_progs:
#3/2 arena_htab/arena_htab_asm:FAIL
#3 arena_htab:FAIL
#95 get_branch_snapshot:FAIL
#172/1 perf_branches/perf_branches_hw:FAIL
#172 perf_branches:FAIL
#434/3 verifier_arena/basic_alloc3:FAIL
#434 verifier_arena:FAIL
Summary: 531/3581 PASSED, 64 SKIPPED, 4 FAILED
Tested-by: Eduard Zingerman <eddyz87@gmail.com>
> PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
> modified vmtest.sh to support local rootfs.
Could you please add this change to the patch-set?
[...]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-02 19:00 ` Björn Töpel
@ 2024-04-03 1:20 ` Conor Dooley
-1 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-04-03 1:20 UTC (permalink / raw)
To: Björn Töpel
Cc: Pu Lehui, Stefan O'Rear, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1.1: Type: text/plain, Size: 2514 bytes --]
On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote:
> >> I still think Lehui's patch is correct; Building a kernel that can boot
> >> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
> >> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
> >> emit Zbb.
> >
> > This sentence is -ENOPARSE to me, did you accidentally omit some words?
> > Additionally he config option has nothing to do with building kernels that
> > boot on multiple platforms, it only controls whether optimisations for Zbb
> > are built so that if Zbb is detected they can be used.
>
> Ugh, sorry about that! I'm probably confused myself.
Reading this back, I a bunch of words too, so no worries...
> >> For these kind of optimizations, (IMO) it's better to let the BPF JIT
> >> decide at run-time.
> >
> > Why is bpf a different case to any other user in this regard?
> > I think that the commit message is misleading and needs to be changed,
> > because the point "the hardware is capable of recognising the Zbb
> > instructions independently..." is completely unrelated to the purpose
> > of the config option. Of course the hardware understanding the option
This should have been "understanding the instructions"...
> > has nothing to do with kernel configuration. The commit message needs to
> > explain why bpf is a special case and is exempt from an
And this s/from an//...
> > I totally understand any point about bpf being different in terms of
> > needing toolchain support, but IIRC it was I who pointed out up-thread.
And "pointed that out".
I always make a mess of these emails that I re-write several times :)
> > The part of the conversation that you're replying to here is about the
> > semantics of the Kconfig option and the original patch never mentioned
> > trying to avoid a dependency on toolchains at all, just kernel
> > configurations. The toolchain requirements I don't think are even super
> > hard to fulfill either - the last 3 versions of ld and lld all meet the
> > criteria.
>
> Thanks for making it more clear, and I agree that the toolchain
> requirements are not hard to fulfull.
>
> My view has been that "BPF is like userland", but I realize now that's
> odd.
Yeah, I can understand that perspective, but it does seem rather odd to
someone that isn't a bpf-ist.
> Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
> the BPF JIT doesn't know about emitting Zbb.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-03 1:20 ` Conor Dooley
0 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-04-03 1:20 UTC (permalink / raw)
To: Björn Töpel
Cc: Pu Lehui, Stefan O'Rear, bpf, linux-riscv, netdev,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]
On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote:
> >> I still think Lehui's patch is correct; Building a kernel that can boot
> >> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
> >> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
> >> emit Zbb.
> >
> > This sentence is -ENOPARSE to me, did you accidentally omit some words?
> > Additionally he config option has nothing to do with building kernels that
> > boot on multiple platforms, it only controls whether optimisations for Zbb
> > are built so that if Zbb is detected they can be used.
>
> Ugh, sorry about that! I'm probably confused myself.
Reading this back, I a bunch of words too, so no worries...
> >> For these kind of optimizations, (IMO) it's better to let the BPF JIT
> >> decide at run-time.
> >
> > Why is bpf a different case to any other user in this regard?
> > I think that the commit message is misleading and needs to be changed,
> > because the point "the hardware is capable of recognising the Zbb
> > instructions independently..." is completely unrelated to the purpose
> > of the config option. Of course the hardware understanding the option
This should have been "understanding the instructions"...
> > has nothing to do with kernel configuration. The commit message needs to
> > explain why bpf is a special case and is exempt from an
And this s/from an//...
> > I totally understand any point about bpf being different in terms of
> > needing toolchain support, but IIRC it was I who pointed out up-thread.
And "pointed that out".
I always make a mess of these emails that I re-write several times :)
> > The part of the conversation that you're replying to here is about the
> > semantics of the Kconfig option and the original patch never mentioned
> > trying to avoid a dependency on toolchains at all, just kernel
> > configurations. The toolchain requirements I don't think are even super
> > hard to fulfill either - the last 3 versions of ld and lld all meet the
> > criteria.
>
> Thanks for making it more clear, and I agree that the toolchain
> requirements are not hard to fulfull.
>
> My view has been that "BPF is like userland", but I realize now that's
> odd.
Yeah, I can understand that perspective, but it does seem rather odd to
someone that isn't a bpf-ist.
> Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
> the BPF JIT doesn't know about emitting Zbb.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-03 1:20 ` Conor Dooley
@ 2024-04-03 10:05 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-04-03 10:05 UTC (permalink / raw)
To: Conor Dooley, Björn Töpel
Cc: Stefan O'Rear, bpf, linux-riscv, netdev, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 2024/4/3 9:20, Conor Dooley wrote:
> On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote:
>
>>>> I still think Lehui's patch is correct; Building a kernel that can boot
>>>> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
>>>> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
>>>> emit Zbb.
>>>
>>> This sentence is -ENOPARSE to me, did you accidentally omit some words?
>>> Additionally he config option has nothing to do with building kernels that
>>> boot on multiple platforms, it only controls whether optimisations for Zbb
>>> are built so that if Zbb is detected they can be used.
>>
>> Ugh, sorry about that! I'm probably confused myself.
>
> Reading this back, I a bunch of words too, so no worries...
>
>>>> For these kind of optimizations, (IMO) it's better to let the BPF JIT
>>>> decide at run-time.
>>>
>>> Why is bpf a different case to any other user in this regard?
>>> I think that the commit message is misleading and needs to be changed,
>>> because the point "the hardware is capable of recognising the Zbb
>>> instructions independently..." is completely unrelated to the purpose
>>> of the config option. Of course the hardware understanding the option
>
> This should have been "understanding the instructions"...
>
>>> has nothing to do with kernel configuration. The commit message needs to
>>> explain why bpf is a special case and is exempt from an
>
> And this s/from an//...
>
>>> I totally understand any point about bpf being different in terms of
>>> needing toolchain support, but IIRC it was I who pointed out up-thread.
>
> And "pointed that out".
>
> I always make a mess of these emails that I re-write several times :)
>
>>> The part of the conversation that you're replying to here is about the
>>> semantics of the Kconfig option and the original patch never mentioned
>>> trying to avoid a dependency on toolchains at all, just kernel
>>> configurations. The toolchain requirements I don't think are even super
>>> hard to fulfill either - the last 3 versions of ld and lld all meet the
>>> criteria.
>>
>> Thanks for making it more clear, and I agree that the toolchain
>> requirements are not hard to fulfull.
>>
>> My view has been that "BPF is like userland", but I realize now that's
>> odd.
>
> Yeah, I can understand that perspective, but it does seem rather odd to
> someone that isn't a bpf-ist.
>
>> Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
>> the BPF JIT doesn't know about emitting Zbb.
>
Hi Conor and Björn,
Thanks for your explanation. I totally agree with what you said,
"CONFIG_RISCV_ISA_ZBB only controls whether optimizations for Zbb are
built so that if Zbb is detected they can be used.".
Since the instructions emited by bpf jit are in kernel space, they
should indeed be aligned in this regard.
PS: It's a bit difficult to understand this,😅 if I'm wrong please don't
hesitate to tell me.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-03 10:05 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-04-03 10:05 UTC (permalink / raw)
To: Conor Dooley, Björn Töpel
Cc: Stefan O'Rear, bpf, linux-riscv, netdev, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 2024/4/3 9:20, Conor Dooley wrote:
> On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote:
>
>>>> I still think Lehui's patch is correct; Building a kernel that can boot
>>>> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
>>>> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
>>>> emit Zbb.
>>>
>>> This sentence is -ENOPARSE to me, did you accidentally omit some words?
>>> Additionally he config option has nothing to do with building kernels that
>>> boot on multiple platforms, it only controls whether optimisations for Zbb
>>> are built so that if Zbb is detected they can be used.
>>
>> Ugh, sorry about that! I'm probably confused myself.
>
> Reading this back, I a bunch of words too, so no worries...
>
>>>> For these kind of optimizations, (IMO) it's better to let the BPF JIT
>>>> decide at run-time.
>>>
>>> Why is bpf a different case to any other user in this regard?
>>> I think that the commit message is misleading and needs to be changed,
>>> because the point "the hardware is capable of recognising the Zbb
>>> instructions independently..." is completely unrelated to the purpose
>>> of the config option. Of course the hardware understanding the option
>
> This should have been "understanding the instructions"...
>
>>> has nothing to do with kernel configuration. The commit message needs to
>>> explain why bpf is a special case and is exempt from an
>
> And this s/from an//...
>
>>> I totally understand any point about bpf being different in terms of
>>> needing toolchain support, but IIRC it was I who pointed out up-thread.
>
> And "pointed that out".
>
> I always make a mess of these emails that I re-write several times :)
>
>>> The part of the conversation that you're replying to here is about the
>>> semantics of the Kconfig option and the original patch never mentioned
>>> trying to avoid a dependency on toolchains at all, just kernel
>>> configurations. The toolchain requirements I don't think are even super
>>> hard to fulfill either - the last 3 versions of ld and lld all meet the
>>> criteria.
>>
>> Thanks for making it more clear, and I agree that the toolchain
>> requirements are not hard to fulfull.
>>
>> My view has been that "BPF is like userland", but I realize now that's
>> odd.
>
> Yeah, I can understand that perspective, but it does seem rather odd to
> someone that isn't a bpf-ist.
>
>> Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
>> the BPF JIT doesn't know about emitting Zbb.
>
Hi Conor and Björn,
Thanks for your explanation. I totally agree with what you said,
"CONFIG_RISCV_ISA_ZBB only controls whether optimizations for Zbb are
built so that if Zbb is detected they can be used.".
Since the instructions emited by bpf jit are in kernel space, they
should indeed be aligned in this regard.
PS: It's a bit difficult to understand this,😅 if I'm wrong please don't
hesitate to tell me.
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-02 16:03 ` Daniel Borkmann
@ 2024-04-03 10:19 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-04-03 10:19 UTC (permalink / raw)
To: Daniel Borkmann, Björn Töpel, bpf, linux-riscv, netdev
Cc: Alexei Starovoitov, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 2024/4/3 0:03, Daniel Borkmann wrote:
> On 4/2/24 4:27 PM, Björn Töpel wrote:
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>> From: Pu Lehui <pulehui@huawei.com>
>>>
>>> This patch relaxes the restrictions on the Zbb instructions. The
>>> hardware
>>> is capable of recognizing the Zbb instructions independently,
>>> eliminating
>>> the need for reliance on kernel compile configurations.
>>>
>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>
>> Should this patch really be part of this series?
>
> No, that should be submitted independently.
>
My initial thought was that I didn't enable CONFIG_RISCV_ISA_ZBB in
config.riscv64, so I should loosen this restriction to enable zbb
optimization. It could not be part of this series.
By the way, after reading what Conor and Björn said, I think we should
align with kernel sematic, that is, emit zbb when CONFIG_RISCV_ISA_ZBB
is enabled and so that if Zbb is detected they can be used.
> Also, given Eduard's comment, it would be great if you could add the
> instructions to tools/testing/selftests/bpf/README.rst even if not in
> a perfect shape, but it would give developers a chance to get started.
>
> Thanks,
> Daniel
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-03 10:19 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-04-03 10:19 UTC (permalink / raw)
To: Daniel Borkmann, Björn Töpel, bpf, linux-riscv, netdev
Cc: Alexei Starovoitov, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 2024/4/3 0:03, Daniel Borkmann wrote:
> On 4/2/24 4:27 PM, Björn Töpel wrote:
>> Pu Lehui <pulehui@huaweicloud.com> writes:
>>> From: Pu Lehui <pulehui@huawei.com>
>>>
>>> This patch relaxes the restrictions on the Zbb instructions. The
>>> hardware
>>> is capable of recognizing the Zbb instructions independently,
>>> eliminating
>>> the need for reliance on kernel compile configurations.
>>>
>>> Signed-off-by: Pu Lehui <pulehui@huawei.com>
>>
>> Should this patch really be part of this series?
>
> No, that should be submitted independently.
>
My initial thought was that I didn't enable CONFIG_RISCV_ISA_ZBB in
config.riscv64, so I should loosen this restriction to enable zbb
optimization. It could not be part of this series.
By the way, after reading what Conor and Björn said, I think we should
align with kernel sematic, that is, emit zbb when CONFIG_RISCV_ISA_ZBB
is enabled and so that if Zbb is detected they can be used.
> Also, given Eduard's comment, it would be great if you could add the
> instructions to tools/testing/selftests/bpf/README.rst even if not in
> a perfect shape, but it would give developers a chance to get started.
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
2024-04-02 23:40 ` Eduard Zingerman
@ 2024-04-03 10:31 ` Pu Lehui
-1 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-04-03 10:31 UTC (permalink / raw)
To: Eduard Zingerman, Daniel Borkmann, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 2024/4/3 7:40, Eduard Zingerman wrote:
> On Sat, 2024-03-30 at 18:12 +0800, Pu Lehui wrote:
> [...]
>
>>> Looks like I won't be able to test this patch-set, unless you have
>>> some writeup on how to create a riscv64 dev environment at hand.
>>> Sorry for the noise
>>
>> Yeah, environmental issues are indeed a developer's nightmare. I will
>> try to do something for the newcomers of riscv64 bpf. At present, I have
>> simply built a docker local vmtest environment [0] based on Bjorn's
>> riscv-cross-builder. We can directly run vmtest within this environment.
>> Hopefully it will help.
>>
>> Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
>
> Hi Pu,
>
> Thank you for sharing the docker file, I've managed to run the tests
> using it. In order to avoid creating files with root permissions I had
> to add the following lines at the end of the Dockerfile:
>
> + RUN useradd --no-create-home --uid 1000 eddy
> + RUN passwd -d eddy
> + RUN echo 'eddy ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
> + # vmtest.sh does 'mount -o loop',
> + # ensure there is a loop device in the container
> + RUN mknod /dev/loop0 b 7 20
>
> Where 'eddy' is my local user with UID 1000.
> Probably this should be made more generic.
> I used the following command to start the container:
>
> docker run -ti -u 1000:1000 \
> --rm -v <path-to-kernel-dir>:/workspace \
> -v <path-to-rootfs-image-dir>:/rootfs \
> --privileged ubuntu-vmtest:latest /bin/bash
>
> Also, I had to add '-d /rootfs/bpf_selftests' option for vmtest.sh in
> order to avoid polluting user directory inside the container.
> Maybe OUTPUT_DIR for vmtest.sh should be mounted as a separate volume.
>
> I agree with Daniel, it would be great to document all of this
Forgot to reply to this in my last email. It my pleasure to do this.
> somewhere in the repo (or even scripted somehow).
>
> Using the specified DENYLIST I get the following stats for test_progs:
>
> #3/2 arena_htab/arena_htab_asm:FAIL
> #3 arena_htab:FAIL
Puranjay has submitted to riscv bpf arena and will be merged soon. So I
didn't add it to DENYLIST.riscv64.
https://lore.kernel.org/bpf/20240326224943.86912-1-puranjay12@gmail.com/
> #95 get_branch_snapshot:FAIL
> #172/1 perf_branches/perf_branches_hw:FAIL
> #172 perf_branches:FAIL
riscv sbi pmu driver not support branch sampling yet. The following
patch should be used for better regression.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493
> #434/3 verifier_arena/basic_alloc3:FAIL
> #434 verifier_arena:FAIL
> Summary: 531/3581 PASSED, 64 SKIPPED, 4 FAILED
>
> Tested-by: Eduard Zingerman <eddyz87@gmail.com>
>
>> PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
>> modified vmtest.sh to support local rootfs.
>
> Could you please add this change to the patch-set?
yep, will try to make it more convenient.
>
> [...]
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64
@ 2024-04-03 10:31 ` Pu Lehui
0 siblings, 0 replies; 60+ messages in thread
From: Pu Lehui @ 2024-04-03 10:31 UTC (permalink / raw)
To: Eduard Zingerman, Daniel Borkmann, bpf, linux-riscv, netdev
Cc: Björn Töpel, Alexei Starovoitov, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Mykola Lysenko,
Manu Bretelle, Pu Lehui
On 2024/4/3 7:40, Eduard Zingerman wrote:
> On Sat, 2024-03-30 at 18:12 +0800, Pu Lehui wrote:
> [...]
>
>>> Looks like I won't be able to test this patch-set, unless you have
>>> some writeup on how to create a riscv64 dev environment at hand.
>>> Sorry for the noise
>>
>> Yeah, environmental issues are indeed a developer's nightmare. I will
>> try to do something for the newcomers of riscv64 bpf. At present, I have
>> simply built a docker local vmtest environment [0] based on Bjorn's
>> riscv-cross-builder. We can directly run vmtest within this environment.
>> Hopefully it will help.
>>
>> Link: https://github.com/pulehui/riscv-cross-builder/tree/vmtest [0]
>
> Hi Pu,
>
> Thank you for sharing the docker file, I've managed to run the tests
> using it. In order to avoid creating files with root permissions I had
> to add the following lines at the end of the Dockerfile:
>
> + RUN useradd --no-create-home --uid 1000 eddy
> + RUN passwd -d eddy
> + RUN echo 'eddy ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
> + # vmtest.sh does 'mount -o loop',
> + # ensure there is a loop device in the container
> + RUN mknod /dev/loop0 b 7 20
>
> Where 'eddy' is my local user with UID 1000.
> Probably this should be made more generic.
> I used the following command to start the container:
>
> docker run -ti -u 1000:1000 \
> --rm -v <path-to-kernel-dir>:/workspace \
> -v <path-to-rootfs-image-dir>:/rootfs \
> --privileged ubuntu-vmtest:latest /bin/bash
>
> Also, I had to add '-d /rootfs/bpf_selftests' option for vmtest.sh in
> order to avoid polluting user directory inside the container.
> Maybe OUTPUT_DIR for vmtest.sh should be mounted as a separate volume.
>
> I agree with Daniel, it would be great to document all of this
Forgot to reply to this in my last email. It my pleasure to do this.
> somewhere in the repo (or even scripted somehow).
>
> Using the specified DENYLIST I get the following stats for test_progs:
>
> #3/2 arena_htab/arena_htab_asm:FAIL
> #3 arena_htab:FAIL
Puranjay has submitted to riscv bpf arena and will be merged soon. So I
didn't add it to DENYLIST.riscv64.
https://lore.kernel.org/bpf/20240326224943.86912-1-puranjay12@gmail.com/
> #95 get_branch_snapshot:FAIL
> #172/1 perf_branches/perf_branches_hw:FAIL
> #172 perf_branches:FAIL
riscv sbi pmu driver not support branch sampling yet. The following
patch should be used for better regression.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?id=ea6873118493
> #434/3 verifier_arena/basic_alloc3:FAIL
> #434 verifier_arena:FAIL
> Summary: 531/3581 PASSED, 64 SKIPPED, 4 FAILED
>
> Tested-by: Eduard Zingerman <eddyz87@gmail.com>
>
>> PS: Since the current rootfs of riscv64 is not in the INDEX, I simply
>> modified vmtest.sh to support local rootfs.
>
> Could you please add this change to the patch-set?
yep, will try to make it more convenient.
>
> [...]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
2024-04-03 10:05 ` Pu Lehui
@ 2024-04-03 12:29 ` Conor Dooley
-1 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-04-03 12:29 UTC (permalink / raw)
To: Pu Lehui
Cc: Björn Töpel, Stefan O'Rear, bpf, linux-riscv,
netdev, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1.1: Type: text/plain, Size: 582 bytes --]
On Wed, Apr 03, 2024 at 06:05:38PM +0800, Pu Lehui wrote:
> Hi Conor and Björn,
>
> Thanks for your explanation. I totally agree with what you said,
> "CONFIG_RISCV_ISA_ZBB only controls whether optimizations for Zbb are built
> so that if Zbb is detected they can be used.".
>
> Since the instructions emited by bpf jit are in kernel space, they should
> indeed be aligned in this regard.
>
> PS: It's a bit difficult to understand this,😅 if I'm wrong please don't
> hesitate to tell me.
I think your understanding is correct. Sorry if I confused you at all!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions
@ 2024-04-03 12:29 ` Conor Dooley
0 siblings, 0 replies; 60+ messages in thread
From: Conor Dooley @ 2024-04-03 12:29 UTC (permalink / raw)
To: Pu Lehui
Cc: Björn Töpel, Stefan O'Rear, bpf, linux-riscv,
netdev, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Mykola Lysenko, Manu Bretelle, Pu Lehui
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
On Wed, Apr 03, 2024 at 06:05:38PM +0800, Pu Lehui wrote:
> Hi Conor and Björn,
>
> Thanks for your explanation. I totally agree with what you said,
> "CONFIG_RISCV_ISA_ZBB only controls whether optimizations for Zbb are built
> so that if Zbb is detected they can be used.".
>
> Since the instructions emited by bpf jit are in kernel space, they should
> indeed be aligned in this regard.
>
> PS: It's a bit difficult to understand this,😅 if I'm wrong please don't
> hesitate to tell me.
I think your understanding is correct. Sorry if I confused you at all!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2024-04-03 12:30 UTC | newest]
Thread overview: 60+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-28 12:49 [PATCH bpf-next 0/5] Support local vmtest for riscv64 Pu Lehui
2024-03-28 12:49 ` Pu Lehui
2024-03-28 12:49 ` [PATCH bpf-next 1/5] selftests/bpf: Enable cross platform testing for local vmtest Pu Lehui
2024-03-28 12:49 ` Pu Lehui
2024-03-28 12:49 ` [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions Pu Lehui
2024-03-28 12:49 ` Pu Lehui
2024-03-28 19:34 ` Stefan O'Rear
2024-03-28 19:34 ` Stefan O'Rear
2024-03-28 22:07 ` Conor Dooley
2024-03-28 22:07 ` Conor Dooley
2024-03-29 10:05 ` Pu Lehui
2024-03-29 10:05 ` Pu Lehui
2024-04-02 14:25 ` Björn Töpel
2024-04-02 14:25 ` Björn Töpel
2024-04-02 17:38 ` Conor Dooley
2024-04-02 17:38 ` Conor Dooley
2024-04-02 19:00 ` Björn Töpel
2024-04-02 19:00 ` Björn Töpel
2024-04-03 1:20 ` Conor Dooley
2024-04-03 1:20 ` Conor Dooley
2024-04-03 10:05 ` Pu Lehui
2024-04-03 10:05 ` Pu Lehui
2024-04-03 12:29 ` Conor Dooley
2024-04-03 12:29 ` Conor Dooley
2024-03-29 11:23 ` Conor Dooley
2024-03-29 11:23 ` Conor Dooley
2024-03-30 10:19 ` Pu Lehui
2024-03-30 10:19 ` Pu Lehui
2024-03-30 10:19 ` Pu Lehui
2024-03-30 10:19 ` Pu Lehui
2024-03-31 17:49 ` Samuel Holland
2024-03-31 17:49 ` Samuel Holland
2024-04-02 14:18 ` Björn Töpel
2024-04-02 14:18 ` Björn Töpel
2024-04-02 14:27 ` Björn Töpel
2024-04-02 14:27 ` Björn Töpel
2024-04-02 16:03 ` Daniel Borkmann
2024-04-02 16:03 ` Daniel Borkmann
2024-04-03 10:19 ` Pu Lehui
2024-04-03 10:19 ` Pu Lehui
2024-03-28 12:49 ` [PATCH bpf-next 3/5] selftests/bpf: Add config.riscv64 Pu Lehui
2024-03-28 12:49 ` Pu Lehui
2024-03-28 12:49 ` [PATCH bpf-next 4/5] selftests/bpf: Add DENYLIST.riscv64 Pu Lehui
2024-03-28 12:49 ` Pu Lehui
2024-03-28 12:49 ` [PATCH bpf-next 5/5] selftests/bpf: Add riscv64 configurations to local vmtest Pu Lehui
2024-03-28 12:49 ` Pu Lehui
2024-03-29 9:08 ` [PATCH bpf-next 0/5] Support local vmtest for riscv64 Eduard Zingerman
2024-03-29 9:08 ` Eduard Zingerman
2024-03-29 10:10 ` Pu Lehui
2024-03-29 10:10 ` Pu Lehui
2024-03-29 19:46 ` Eduard Zingerman
2024-03-29 19:46 ` Eduard Zingerman
2024-03-30 10:12 ` Pu Lehui
2024-03-30 10:12 ` Pu Lehui
2024-03-30 10:12 ` Pu Lehui
2024-03-30 10:12 ` Pu Lehui
2024-04-02 23:40 ` Eduard Zingerman
2024-04-02 23:40 ` Eduard Zingerman
2024-04-03 10:31 ` Pu Lehui
2024-04-03 10:31 ` Pu Lehui
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.