Re: [RFC PATCH 06/10] .agents/skills: add qemu-testing skill

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, May 05, 2026 at 06:01:01PM +0100, Alex Bennée wrote:
>> This provides basic instructions for running tests.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>  .agents/skills/qemu-testing/SKILL.md | 53 ++++++++++++++++++++++++++++
>>  1 file changed, 53 insertions(+)
>>  create mode 100644 .agents/skills/qemu-testing/SKILL.md
>> 
>> diff --git a/.agents/skills/qemu-testing/SKILL.md b/.agents/skills/qemu-testing/SKILL.md
>> new file mode 100644
>> index 00000000000..3b7b42109e1
>> --- /dev/null
>> +++ b/.agents/skills/qemu-testing/SKILL.md
>> @@ -0,0 +1,53 @@
>> +---
>> +name: qemu-testing
>> +description: Provides instructions on how to find, list, and run
>> individual tests for QEMU (Unit, QTest, Functional, TCG). You MUST
>> use this skill whenever the user asks about tests, wants to list
>> available tests, or wants to run any test in a build directory, even
>> for simple exploratory queries like "what tests can I run". It
>> includes details about spawning sub-agents.
>> +license: GPL-2.0-or-later
>> +---
>> +
>> +# Instructions
>> +To run QEMU tests, you can use several different suites depending
>> on what you are testing. **Note**: Ensure you have a recent build of
>> QEMU before running tests. Use the `qemu-build` skill if you need to
>> configure or run a build.
>> +
>> +## General Test Suites
>> +- **Unit Tests**: `make check-unit`
>> +- **QTest (Device emulation)**: `make check-qtest`
>> +- **Functional Tests (Python based)**: `make check-functional`
>> +- **TCG Tests (CPU instruction tests)**: `make check-tcg`
>> +
>> +## Launching Tests
>> +**Crucial**: You MUST NEVER run a test suites directly in the main
>> agent context. You MUST ALWAYS launch them by spawning a sub-agent.
>> Pass the specific build or test commands, along with the required
>> build directory, in the `task` argument. Give the subagent explicit
>> instructions on what to verify and what to report back to you.
>> +For example: `task: "Navigate to builds/debug and check what meson tests touch replay and report back."` or `task: "Run make check-tcg in builds/arm and summarize any failing tests."`
>> +
>> +### From the Build Directory
>> +Most individual tests from within a build directory. Most (unit, qtest, block, functional) can be individually selected and run via meson.
>> +
>> +As QEMU often needs a newer meson than the build host you should use the build `pyenv` to launch it:
>> +- **Example**: `./pyvenv/bin/meson test --suite thorough --list` to see what tests are in the thorough test suite
>> +
>> +## Running Individual Tests
>> +
>> +### Meson Test Runner (Unit, QTest, Functional, softfloat etc)
>> +To run a single test, you can use the meson test runner from within your pyvenv:
>> +`./pyvenv/bin/meson test [testname]`
>> +Example: `./pyvenv/bin/meson test qtest-x86_64/boot-serial-test`
>> +
>> +### TCG Tests
>> +To run individual TCG tests for a specific architecture:
>> +1. Navigate to the relevant build directory, e.g.: `cd tests/tcg/aarch64-softmmu`
>> +2. Run a specific test with make: `make run-[testname]`
>> +   Example: `make run-memory-sve`
>> +3. Use `make help` within the architecture directory to see the full list of available tests.
>> +
>> +### Functional Tests
>> +Individual functional tests can be run directly using the run script although from the source directory:
>> +- **Example**: `./builds/all/run tests/functional/aarch64/test_virt_vbsa.py`
>> +
>> +### Environment Variables
>> +- `V=1` for verbose output from tests.
>> +- `SPEED=slow` to run slower tests that are normally skipped.
>
> When I read this, I note there is some significant overlap with what
> we write in docs/devel/testing/. 
>
> Would it still be effective enough to merely point the agents to
> docs/devel/testing and get rid of most text in this section ?

The intention of skills is to be as concise as possible to save on token
cost. We could certainly put a link to the main document so it can read
it for more details if needed.

>
>> +
>> +## Reporting Results
>> +**Crucial**: After completing the build and test tasks, provide a concise summary of the results to the calling agent.
>> +1. **Summary**: State whether the build and tests passed or failed.
>> +2. **Failure Excerpts**: If any task fails, include relevant excerpts from the logs (e.g., compiler errors, test failures).
>> +3. **Full Paths**: Always provide the **absolute file paths** to the full logs and result sets for further inspection.
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro