(please ignore v3 which was bogus, but don't miss the discussion in it about the caveats of this approach: https://lore.kernel.org/r/87jzrkdne2....@suse.de)
This adds support for running migration-test with two different QEMU versions to test migration compatibility. The tests automatically choose the latest machine type supported by both QEMU versions. changes: - added a cleanup function for the allocated strings in the machine list. The suggestion of making a copy of the list won't work because keeping the structure around to avoid freeing memory, and caching the list are two separate things that only make sense together at qtest_get_machines(). Outside of it, code can just free memory normally and caching doesn't make sense because there's no QMP call; - kept strdups for the reasons mentioned above; - added a message when we're unable to find a common machine type (should never happen); - changed the default x86_64 machine to q35; - new patch to fix booting with the a-b bootsector on q35; - added machine_opts for the options after the comma; - used machine_alias and machine for the variable names; - added support for specifying the machine type; CI run: https://gitlab.com/farosas/qemu/-/pipelines/1041561223 v3: https://lore.kernel.org/r/20231018140736.3618-1-faro...@suse.de v2: https://lore.kernel.org/r/20231006123910.17759-1-faro...@suse.de changes: - introduce *_with_env variants of the relevant functions [Daniel, Juan] - keep the requirement for having the QTEST_QEMU_BINARY always present. qtest_get_arch() is used extensively in the qtest_add* functions. It would be too much churn to pass a different binary into it. - with this^ we also need to keep the requirement for using only one of SRC|DST. Otherwise it would be confusing to have three binaries listed. - query the alias to find out the machine types [Daniel] I haven't looked into the docker part for now. I think Daniel's suggestion of QTEST_QEMU_BINARY_SRC='podman run ... qemu-system-foo' looks interesting. Do we have the latest release already built in the registry at any given point? Thanks v1: https://lore.kernel.org/r/20231003141932.2367-1-faro...@suse.de Hi, I had this WIP patch laying around that seems to fit Juan's vision about testing older machine types. It is a very rough draft for now, but it may be useful for kickstarting the discussion. With this we can give the tests two different QEMU versions. The test picks the older machine type between the two and runs the whole migration-test suite. We'd just need a way to provide the older build. Currently I'm doing this by hand. sample output: # Using two different QEMU binaries. Common machine type: pc-i440fx-8.1 ... # Using ./qemu-system-x86_64 (v8.1.0-952-g8a940312a2-dirty) as migration source ... # Using ../build-8.1.0/qemu-system-x86_64 (v8.1.0-dirty) as migration destination Let me know what you think. Fabiano Rosas (12): tests/qtest: Allow qtest_qemu_binary to use a custom environment variable tests/qtest: Introduce qtest_init_with_env tests/qtest: Allow qtest_get_machines to use an alternate QEMU binary tests/qtest: Introduce qtest_has_machine_with_env tests/qtest: Introduce qtest_resolve_machine_alias tests/qtest/migration: Introduce find_common_machine_version tests/qtest/migration: Define a machine for all architectures tests/qtest/migration: Specify the geometry of the bootsector tests/qtest/migration: Set q35 as the default machine for x86_86 tests/qtest/migration: Support more than one QEMU binary tests/qtest/migration: Allow user to specify a machine type tests/qtest: Don't print messages from query instances tests/qtest/libqtest.c | 98 ++++++++++++++++++++++++++++----- tests/qtest/libqtest.h | 32 +++++++++++ tests/qtest/migration-helpers.c | 52 +++++++++++++++++ tests/qtest/migration-helpers.h | 4 ++ tests/qtest/migration-test.c | 50 +++++++++++++++-- 5 files changed, 215 insertions(+), 21 deletions(-) -- 2.35.3
