Commits on Jan 25, 2024

1. run-vmtest: action to test bpf using danobi/vmtest …

   Add a new action to mimick what used to be done by `run-qemu`.
   
   This action is roughly a `cp run-qemu run-vmtest` in term of functionalities.
   See end of this commit message for a rationale of this change.
   
   Just like `run-qemu` assumes the presence of a rootfs which is provisioned with
   a copy of the script from `ci/vmtest/run_selftests.sh`, `run-vmtest` assumes the
   presence of `ci/vmtest/vmtest_selftests.sh` and will run it.
   
   `vmtest_selftests.sh` functionally does the same as `run_selftests.sh` with a
   few adjustments to make it work in the `vmtest` world` and leave in the "callee"
   repository, not libbpf-ci.
   
   `print_test_summary.py` was copied over unchanged. Later diff will remove the
   version from `run-qemu` and point to this one instead.
   
   `action.yml` needs to install a few tools that were historically baked in the rootfs.
   A bunch of parameters are now historical.... this diff does not attempt to remove them
   yet. This will be address later too and will probably change as libbpf/libbpf use case
   is merged in.
   
   `run.sh` gets rid of the logic to create the `qemu` one-liner as well as the
   downloading of files from within the rootfs, and adjust it to using files on
   disk that were left over by the test run.
   
   Full end-to-end testing will be done through a PR in https://github.com/kernel-patches/vmtest
   
   == Main functional difference between `run-qemu` and `run-vmtest`.
   
   `run-qemu` runs the kernel inside a rootfs which is isolated from the host FS,
   meaning that we potentially have a host in which we build the kernel/selftests
   which is different than the host we run in. Causing depedency issues, see libbpf#83 and
   to some extends libbpf#103 .
   We could work around this with statically built binaries, but because of the different
   rootfs, we end up having to maintain rootfs *and* doing a dance of copying files
   in and out of the rootfs (through the prepare-rootfs action), which is slow, pulls
   a fair amount of bytes through the network...
   
   `run-vmtest` on the other hand does mount the host rootfs (read-only) and shares the
   current directory (read-write) under /mnt/vmtest.
   This resolves 2 things for us.
   1. We don't have libraries incompatibilitie issues anymore as the building OS
   and the OS running the tests will be the same.
   1. We don't need to copy files in and out of the root fs. The files are already
   on the FS seen by the VM, and files dumped by the tests are directly accessible
   outside the VM.
   
   On top of this, `vmtest` also handles the peculiarities of crafting the right
   qemu one-liner.
   
   Signed-off-by: Manu Bretelle <[email protected]>

   

   chantra committed Jan 25, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 91765e0
   • Browse repository at this point

   Copy the full SHA

   91765e0 View commit details

   Browse the repository at this point in the history

2. run-qemu: make use of run-qemu/print_test_summary.py …

   Avoid keeping duplicated version of the script by re-using the one now located
   under run-vmtest.
   
   Signed-off-by: Manu Bretelle <[email protected]>

   

   chantra committed Jan 25, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 3826a90
   • Browse repository at this point

   Copy the full SHA

   3826a90 View commit details

   Browse the repository at this point in the history

3. run-vmtest: convert tests from comma-separated list to space-separated. …

   vmtest_selftests.sh expect them to be space-separated.
   
   Signed-off-by: Manu Bretelle <[email protected]>

   

   chantra committed Jan 25, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for b487b1b
   • Browse repository at this point

   Copy the full SHA

   b487b1b View commit details

   Browse the repository at this point in the history