drgn/vmtest
Omar Sandoval 35dcd78943 vmtest.kbuild: also check image_name under arch/$SRCARCH/boot
This is a workaround for AArch64 and Arm on old kernel versions.

Signed-off-by: Omar Sandoval <osandov@osandov.com>
2023-02-16 02:23:04 -08:00
..
patches vmtest.kbuild: add patch to allow enabling /proc/kcore on ARM 2023-02-16 02:23:04 -08:00
__init__.py Rewrite virtual machine testing setup 2020-04-02 17:35:24 -07:00
asynciosubprocess.py Relicense drgn from GPLv3+ to LGPLv2.1+ 2022-11-01 17:05:16 -07:00
config.py vmtest.kbuild: set localversion on command line instead of kconfig 2023-02-16 02:17:20 -08:00
download.py vmtest.download: support downloading cross compilers from kernel.org 2023-02-14 16:58:21 -08:00
enter_kdump.py Relicense drgn from GPLv3+ to LGPLv2.1+ 2022-11-01 17:05:16 -07:00
githubapi.py vmtest: set raise_for_status=True for GitHub API requests 2022-12-28 23:24:52 -08:00
kbuild.py vmtest.kbuild: also check image_name under arch/$SRCARCH/boot 2023-02-16 02:23:04 -08:00
manage.py vmtest.kbuild: add --download-compiler 2023-02-14 16:58:21 -08:00
onoatimehack.c Relicense drgn from GPLv3+ to LGPLv2.1+ 2022-11-01 17:05:16 -07:00
README.rst vmtest: don't use BusyBox 2022-08-01 11:23:26 -07:00
vm.py vmtest.vm: support other architectures 2023-02-14 16:58:21 -08:00

drgn VM Testing
===============

drgn has a significant amount of code (both core and in helpers) which is
dependent on the Linux kernel version. This code is tested on multiple Linux
kernel versions in a virtual machine. These tests can be run on all supported
kernels with ``python3 setup.py test -K``. This requires QEMU and zstd to be
installed.

Tests can also be run on specific kernels with ``-k``. This takes a
comma-separated list of kernels which are wildcard patterns (e.g., ``5.6.*``)
matching a kernel release hosted on GitHub (see below).

Architecture
------------

The goal of vmtest is to run tests in the same userspace environment as the
host, but with a different kernel. The host runs the virtual machine with `QEMU
<https://www.qemu.org/>`_ (see the `vmtest.vm <vm.py>`_ module).

The guest mounts the host's root filesystem as its own root filesystem via
`VirtFS <https://www.linux-kvm.org/page/VirtFS>`_. It is mounted read-only for
safety. To support modifications, the guest uses `OverlayFS
<https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt>`_ to
overlay a read-write tmpfs over the VirtFS root. It also mounts the kernel
modules and vmlinux via VirtFS.

The guest runs an init shell script which sets up the system and filesystem
hierarchy, runs a command, and returns the exit status via `virtio-serial
<https://fedoraproject.org/wiki/Features/VirtioSerial>`_.

This infrastructure is all generic. The drgn-specific parts are:

1. The kernel builds. These are configured with a minimal configuration
   including everything required to run drgn and the Linux kernel helper tests.
   Each build is packaged as a tarball containing ``vmlinux``, ``vmlinuz``, and
   kernel modules. These packages are built by the `vmtest.kbuild <kbuild.py>`_
   module. They are hosted in a `GitHub release
   <https://github.com/osandov/drgn/releases/tag/vmtest-assets>`_ which is
   managed via the GitHub API by the `vmtest.manage <manage.py>`_ CLI. New
   kernel releases are built and uploaded by a `GitHub Actions workflow
   <../.github/workflows/vmtest-build.yml>`_. The packages are downloaded by
   the `vmtest.download <download.py>`_ module.
2. A `kernel module <../tests/linux_kernel/kmod>`_ for testing drgn
   functionality that cannot be tested through userspace APIs.
3. The test command itself. This is just some ``setup.py`` glue to build the
   test kernel module and run the VM with the proper invocation of the Python
   `unittest command line interface
   <https://docs.python.org/3/library/unittest.html#test-discovery>`_.

The ``vmtest.vm`` and ``vmtest.download`` modules also have CLIs for testing
purposes. These are subject to change.