On Mon, Jan 25, 2021 at 06:09:48PM -0800, Andrii Nakryiko wrote: SNIP > > 7. Is it just me, or when ./test_progs is run inside VM, it's output > is somehow heavily buffered and delayed? I get no output for a while, > and then a whole bunch of lines with already passed tests. Curious if > anyone else noticed that as well. When I run the same image locally > and manually (not through your script), I don't have this issue. I see the same thing, big delay on the test_prog start and then chunk updates of its output jirka > > 8. I noticed that even if the command succeeds (e.g., ./test_progs in > my case), the script exits with non-zero error code (32 in my case). > That's suboptimal, because you can't use that script to detect test > failures. > > But again, it's the polish feedback, great work! > > > tools/testing/selftests/bpf/run_in_vm.sh | 353 +++++++++++++++++++++++ > > 1 file changed, 353 insertions(+) > > create mode 100755 tools/testing/selftests/bpf/run_in_vm.sh > > > > diff --git a/tools/testing/selftests/bpf/run_in_vm.sh b/tools/testing/selftests/bpf/run_in_vm.sh > > new file mode 100755 > > index 000000000000..09bb9705acb3 > > --- /dev/null > > +++ b/tools/testing/selftests/bpf/run_in_vm.sh > > @@ -0,0 +1,353 @@ > > +#!/bin/bash > > +# SPDX-License-Identifier: GPL-2.0 > > + > > +set -u > > +set -e > > + > > +QEMU_BINARY="${QEMU_BINARY:="qemu-system-x86_64"}" > > +X86_BZIMAGE="arch/x86/boot/bzImage" > > Might be worth it to mention that this only works with x86_64 (due to > image restrictions at least, right?). > > > +DEFAULT_COMMAND="./test_progs" > > +MOUNT_DIR="mnt" > > +ROOTFS_IMAGE="root.img" > > +OUTPUT_DIR="$HOME/.bpf_selftests" > > +KCONFIG_URL="https://raw.githubusercontent.com/libbpf/libbpf/master/travis-ci/vmtest/configs/latest.config" > > +INDEX_URL="https://raw.githubusercontent.com/libbpf/libbpf/master/travis-ci/vmtest/configs/INDEX" > > +NUM_COMPILE_JOBS="$(nproc)" > > + > > +usage() > > +{ > > + cat <<EOF > > +Usage: $0 [-k] [-i] [-d <output_dir>] -- [<command>] > > + > > +<command> is the command you would normally run when you are in > > +tools/testing/selftests/bpf. e.g: > > + > > + $0 -- ./test_progs -t test_lsm > > + > > +If no command is specified, "${DEFAULT_COMMAND}" will be run by > > +default. > > + > > +If you build your kernel using KBUILD_OUTPUT= or O= options, these > > +can be passed as environment variables to the script: > > + > > + O=<path_relative_to_cwd> $0 -- ./test_progs -t test_lsm > > "relative_to_cwd" is a bit misleading, it could be an absolute path as > well, I presume. So I'd just say "O=<kernel_build_path>" or something > along those lines. > > > + > > +or > > + > > + KBUILD_OUTPUT=<path_relative_to_cwd> $0 -- ./test_progs -t test_lsm > > + > > [...] >