For reference: On 6/9/2026 2:47 PM, Pierrick Bouvier wrote: > It implements all requirements listed on original thread [1], except cross > container support, which can be easily added on top once we agree on the base. > [1] https://lore.kernel.org/qemu-devel/[email protected]/ >
>> - support building tests with containers to be implemented in future version, but nothing blocking. >> - handle all existing tests >> - per-arch *-user and *-softmmu >> - including post test validation checks (conditional-diff-out, validate-memory-counts.py, etc...) Done by adding the 'wrapper' concept. >> - per-target overrides (some targets are broken for some tests) Each target includes what it wants, so it's free to skip/customize any test. >> - custom QEMU_OPTS for some tests Done by adding 'qemu_args'. >> - including sub-arch tests (e.g. x86_64 includes i386, mips64el includes mips64 etc...) Each target includes what it wants, including sub-arch if needed. >> - multiarch tests for all *-user targets >> - multiarch tests for all *-softmmu targets with boot.S >> - gdbstub tests Done by adding 'gdb_test'. >> - don't forget gdb feature probing for arch and arch features (e.g. GDB_HAS_SME_TILES) Done by comparing gdb version as needed from meson. >> - record/replay tests Done by adding a record_replay wrapper. >> - tcg plugin tests Done by adding 'plugin_test'. >> - modulate plugins over tests to avoid combinatorial explosion Not implemented at the moment, but we can use any heuristic to limit the PxT expansion. >> - filter some plugins from general testing (e.g. patch) >> - filter some plugins based on mode (e.g. syscall) >> - specific plugins with specific tests (e.g. patch, memory) Each plugin test is explicit, so we are free to implement any policy. >> - support build variations Done by adding 'cflags' and ensuring we can't create an accidental duplication. >> - compiler feature probing to gate tests Done directly in meson by testing compiler. >> - custom cflags for some tests Done by adding 'cflags'. >> - alternate cflag builds for some tests (e.g. sha512-[vector|sse|mvx|...]) Done by specifying a different 'cflags', and an alternate executable name with 'exe_name'. We ensure duplication is explicit. >> - build scripts (e.g. test-mmx.py) Not needed in aarch64 at the moment. For this use case, we'll generate a header using a custom target, which will be a dependency of final test. Regards, Pierrick
