[PATCH bpf-next 0/5] Support local vmtest for riscv64

[PATCH bpf-next 0/5] Support local vmtest for riscv64

[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

[PATCH bpf-next 0/5] Support local vmtest for riscv64

[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

[PATCH bpf-next 1/5] selftests/bpf: Enable cross platform testing for local vmtest

[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

[PATCH bpf-next 1/5] selftests/bpf: Enable cross platform testing for local vmtest

[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

[PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

[PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Stefan O'Rear]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Stefan O'Rear]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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 --]

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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 --]

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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 --]

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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.

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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 --]

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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 --]

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

[-- 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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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.
>   
> 

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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.
>   
> 

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Samuel Holland]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Samuel Holland]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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/

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Björn Töpel]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Daniel Borkmann]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Daniel Borkmann]

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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

Re: [PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[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

[PATCH bpf-next 3/5] selftests/bpf: Add config.riscv64

[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

[PATCH bpf-next 3/5] selftests/bpf: Add config.riscv64

[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

[PATCH bpf-next 4/5] selftests/bpf: Add DENYLIST.riscv64

[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

[PATCH bpf-next 4/5] selftests/bpf: Add DENYLIST.riscv64

[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

[PATCH bpf-next 5/5] selftests/bpf: Add riscv64 configurations to local vmtest

[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

[PATCH bpf-next 5/5] selftests/bpf: Add riscv64 configurations to local vmtest

[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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[Eduard Zingerman]

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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[Eduard Zingerman]

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}))
 

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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}))
>   

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[Eduard Zingerman]

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.

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[Eduard Zingerman]

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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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}"

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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}"

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[Eduard Zingerman]

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?

[...]

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[Eduard Zingerman]

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

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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.

> 
> [...]

Re: [PATCH bpf-next 0/5] Support local vmtest for riscv64

[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