232c3a848e
Replace the footnotes with inline links whenever the footnote text consists of nothing but the URL. While at it, make the link texts consistent in the surrounding areas, for example avoiding usage of "here" for the link's text. In the case of acpi-bits.rst this fixes a build failure with Sphinx 8.1.0, because the FOSDEM link was duplicated in the paragraph and the new version is a lot stricter about unreferenced footnotes. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
156 lines
7.8 KiB
ReStructuredText
156 lines
7.8 KiB
ReStructuredText
==================================
|
|
ACPI/SMBIOS testing using biosbits
|
|
==================================
|
|
************
|
|
Introduction
|
|
************
|
|
Biosbits is a software written by Josh Triplett that can be downloaded
|
|
from https://biosbits.org/. The github codebase can be found
|
|
`here <https://github.com/biosbits/bits/tree/master>`__. It is a software that
|
|
executes the bios components such as acpi and smbios tables directly through
|
|
acpica bios interpreter (a freely available C based library written by Intel,
|
|
downloadable from https://acpica.org/ and is included with biosbits) without an
|
|
operating system getting involved in between. Bios-bits has python integration
|
|
with grub so actual routines that executes bios components can be written in
|
|
python instead of bash-ish (grub's native scripting language).
|
|
There are several advantages to directly testing the bios in a real physical
|
|
machine or in a VM as opposed to indirectly discovering bios issues through the
|
|
operating system (the OS). Operating systems tend to bypass bios problems and
|
|
hide them from the end user. We have more control of what we wanted to test and
|
|
how by being as close to the bios on a running system as possible without a
|
|
complicated software component such as an operating system coming in between.
|
|
Another issue is that we cannot exercise bios components such as ACPI and
|
|
SMBIOS without being in the highest hardware privilege level, ring 0 for
|
|
example in case of x86. Since the OS executes from ring 0 whereas normal user
|
|
land software resides in unprivileged ring 3, operating system must be modified
|
|
in order to write our test routines that exercise and test the bios. This is
|
|
not possible in all cases. Lastly, test frameworks and routines are preferably
|
|
written using a high level scripting language such as python. OSes and
|
|
OS modules are generally written using low level languages such as C and
|
|
low level assembly machine language. Writing test routines in a low level
|
|
language makes things more cumbersome. These and other reasons makes using
|
|
bios-bits very attractive for testing bioses. More details on the inspiration
|
|
for developing biosbits and its real life uses were presented `at Plumbers
|
|
in 2011 <Plumbers_>`__ and `at Linux.conf.au in 2012 <Linux.conf.au_>`__.
|
|
|
|
For QEMU, we maintain a fork of bios bits in `gitlab`_, along with all
|
|
the dependent submodules. This fork contains numerous fixes, a newer
|
|
acpica and changes specific to running these functional QEMU tests using
|
|
bits. The author of this document is the current maintainer of the QEMU
|
|
fork of bios bits repository. For more information, please see `the
|
|
author's FOSDEM presentation <FOSDEM_>`__ on this bios-bits based test framework.
|
|
|
|
.. _Plumbers: https://blog.linuxplumbersconf.org/2011/ocw/system/presentations/867/original/bits.pdf
|
|
.. _Linux.conf.au: https://www.youtube.com/watch?v=36QIepyUuhg
|
|
.. _gitlab: https://gitlab.com/qemu-project/biosbits-bits
|
|
.. _FOSDEM: https://fosdem.org/2024/schedule/event/fosdem-2024-2262-exercising-qemu-generated-acpi-smbios-tables-using-biosbits-from-within-a-guest-vm-/
|
|
|
|
*********************************
|
|
Description of the test framework
|
|
*********************************
|
|
|
|
Under the directory ``tests/functional/``, ``test_acpi_bits.py`` is a QEMU
|
|
functional test that drives all this.
|
|
|
|
A brief description of the various test files follows.
|
|
|
|
Under ``tests/functional/`` as the root we have:
|
|
|
|
::
|
|
|
|
├── acpi-bits
|
|
│ ├── bits-config
|
|
│ │ └── bits-cfg.txt
|
|
│ ├── bits-tests
|
|
│ ├── smbios.py2
|
|
│ ├── testacpi.py2
|
|
│ └── testcpuid.py2
|
|
├── test_acpi_bits.py
|
|
|
|
* ``tests/functional``:
|
|
|
|
``test_acpi_bits.py``:
|
|
This is the main python functional test script that generates a
|
|
biosbits iso. It then spawns a QEMU VM with it, collects the log and reports
|
|
test failures. This is the script one would be interested in if they wanted
|
|
to add or change some component of the log parsing, add a new command line
|
|
to alter how QEMU is spawned etc. Test writers typically would not need to
|
|
modify this script unless they wanted to enhance or change the log parsing
|
|
for their tests. In order to enable debugging, you can set **V=1**
|
|
environment variable. This enables verbose mode for the test and also dumps
|
|
the entire log from bios bits and more information in case failure happens.
|
|
You can also set **BITS_DEBUG=1** to turn on debug mode. It will enable
|
|
verbose logs and also retain the temporary work directory the test used for
|
|
you to inspect and run the specific commands manually.
|
|
|
|
In order to run this test, please perform the following steps from the QEMU
|
|
build directory (assuming that the sources are in ".."):
|
|
::
|
|
|
|
$ export PYTHONPATH=../python:../tests/functional
|
|
$ export QEMU_TEST_QEMU_BINARY=$PWD/qemu-system-x86_64
|
|
$ python3 ../tests/functional/test_acpi_bits.py
|
|
|
|
The above will run all acpi-bits functional tests (producing output in
|
|
tap format).
|
|
|
|
You can inspect the log files in tests/functional/x86_64/test_acpi_bits.*/
|
|
for more information about the run or in order to diagnoze issues.
|
|
If you pass V=1 in the environment, more diagnostic logs will be put into
|
|
the test log.
|
|
|
|
* ``tests/functional/acpi-bits/bits-config``:
|
|
|
|
This location contains biosbits configuration files that determine how the
|
|
software runs the tests.
|
|
|
|
``bits-config.txt``:
|
|
This is the biosbits config file that determines what tests
|
|
or actions are performed by bits. The description of the config options are
|
|
provided in the file itself.
|
|
|
|
* ``tests/functional/acpi-bits/bits-tests``:
|
|
|
|
This directory contains biosbits python based tests that are run from within
|
|
the biosbits environment in the spawned VM. New additions of test cases can
|
|
be made in the appropriate test file. For example, new acpi tests can go
|
|
into testacpi.py2 and one would call testsuite.add_test() to register the new
|
|
test so that it gets executed as a part of the ACPI tests.
|
|
It might be occasionally necessary to disable some subtests or add a new
|
|
test that belongs to a test suite not already present in this directory. To
|
|
do this, please clone the bits source from
|
|
https://gitlab.com/qemu-project/biosbits-bits/-/tree/qemu-bits.
|
|
Note that this is the "qemu-bits" branch and not the "bits" branch of the
|
|
repository. "qemu-bits" is the branch where we have made all the QEMU
|
|
specific enhancements and we must use the source from this branch only.
|
|
Copy the test suite/script that needs modification (addition of new tests
|
|
or disabling them) from python directory into this directory. For
|
|
example, in order to change cpuid related tests, copy the following
|
|
file into this directory and rename it with .py2 extension:
|
|
https://gitlab.com/qemu-project/biosbits-bits/-/blob/qemu-bits/python/testcpuid.py
|
|
Then make your additions and changes here. Therefore, the steps are:
|
|
|
|
(a) Copy unmodified test script to this directory from bits source.
|
|
(b) Add a SPDX license header.
|
|
(c) Perform modifications to the test.
|
|
|
|
Commits (a), (b) and (c) preferably should go under separate commits so that
|
|
the original test script and the changes we have made are separated and
|
|
clear. (a) and (b) can sometimes be combined into a single step.
|
|
|
|
The test framework will then use your modified test script to run the test.
|
|
No further changes would be needed. Please check the logs to make sure that
|
|
appropriate changes have taken effect.
|
|
|
|
The tests have an extension .py2 in order to indicate that:
|
|
|
|
(a) They are python2.7 based scripts and not python 3 scripts.
|
|
(b) They are run from within the bios bits VM and is not subjected to QEMU
|
|
build/test python script maintenance and dependency resolutions.
|
|
(c) They need not be loaded by the test framework by accident when running
|
|
tests.
|
|
|
|
|
|
Author: Ani Sinha <anisinha@redhat.com>
|
|
|