mirror of
https://github.com/JakeHillion/drgn.git
synced 2024-12-22 17:23:06 +00:00
859b3c5053
My Arm VM fails to boot on QEMU 7.2.1 after the following sequence of events on the kernel console: pci-host-generic 4010000000.pcie: can't claim ECAM area [mem 0x10000000-0x1fffffff]: address conflict with pcie@10000000 [mem 0x10000000-0x3efeffff] pci-host-generic: probe of 4010000000.pcie failed with error -16 ... 9pnet_virtio: no channels available for device /dev/root VFS: Cannot open root device "" or unknown-block(0,0): error -2 Please append a correct "root=" boot option; here are the available partitions: Can't find any bdev filesystem to be used for mount! Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Turning off highmem fixes the conflict. (I think this previously worked without highmem=off on Arch Linux, so maybe there's something different in Fedora's QEMU.) Signed-off-by: Omar Sandoval <osandov@osandov.com> |
||
---|---|---|
.. | ||
patches | ||
__init__.py | ||
asynciosubprocess.py | ||
config.py | ||
download.py | ||
enter_kdump.py | ||
githubapi.py | ||
kbuild.py | ||
kmod.py | ||
manage.py | ||
onoatimehack.c | ||
README.rst | ||
vm.py |
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.