qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 5/5] tests/functional: Convert the migration avocado test


From: Thomas Huth
Subject: Re: [PATCH v2 5/5] tests/functional: Convert the migration avocado test
Date: Wed, 18 Dec 2024 17:11:43 +0100
User-agent: Mozilla Thunderbird

On 18/12/2024 17.00, Daniel P. Berrangé wrote:
On Wed, Dec 18, 2024 at 04:51:24PM +0100, Thomas Huth wrote:
On 18/12/2024 14.51, Fabiano Rosas wrote:
Thomas Huth <thuth@redhat.com> writes:

Now that we've got a find_free_port() function in the functional
test framework, we can convert the migration test, too.
While the original avocado test was only meant to run on aarch64,
ppc64 and x86, we can turn this into a more generic test by now
and run it on all architectures that have a default machine that
ships with a working firmware.

I'd rather drop this test. I haven't looked at it in ages and it has
never been useful.

I think I agree for the scope of the old avocado test - x86, ppc64 and
aarch64 certainly have better test coverage by the qtest already... but we
don't have any test coverage for other architectures at all yet, which is
bad (see below).

So if you like I can change the patch so that the test is not run on x86,
ppc64 and aarch64 anymore, just on the other architectures that do not have
test coverage by the qtest yet?

I haven't been following the development of the
functional suite so this might not apply this time (fingers crossed),
but Python tests have always been a pain to work with.

Well, one of the motivations with the functional test framework was to
simplify things. You can now run the individual tests without any test
runner at all, what makes debugging way easier (see
docs/devel/testing/functional.rst for details)!

About adding more architectures to the set, this is not simply enabling
more testing, it is also adding workload to maintain these other arches
that were never tested with migration. Is that something we want?

I think yes. Otherwise the bugs are just dormant until someone hits the
issue, making bisection way more complicated later.
Remember this one for example:

  https://mail.gnu.org/archive/html/qemu-commits/2023-02/msg00030.html

?

It would have been good to have a migration test for alpha in the CI, then
we could have prevented that bug from being merged.

IIUC, we run the migration-test  qtest for *every* softmmu target.

So, assuming you're referring to alpha guest, we were already
exercising it.

Unless I missed something, you got that wrong. Have a look at tests/qtest/meson.build: The migration-test is only added for i386/x86_64, ppc64, aarch64 and s390x (since you need a special boot / guest code for this test).

Anyway, I think a true functional test for migration is relevant
to keep, as long as we make it clearly different from the qtest.
A simple smoke test using a real Linux guest is different enough
from our hand crafted boot sector that I think it is valuable
coverage. Even better if we make the functional test add *lots*
of different devices.

Agreed, that's a good idea. But for a start, I'd first like to convert the avocado test so that we finally can clean the tests/avocado folder.

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]