(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.fsf@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-farosas@suse.de
v2:
https://lore.kernel.org/r/20231006123910.17759-1-farosas@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-farosas@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