[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v5 7/9] target/avocado: Pass parameters to migration test
From: |
Fabiano Rosas |
Subject: |
Re: [RFC PATCH v5 7/9] target/avocado: Pass parameters to migration test on aarch64 |
Date: |
Mon, 23 Jan 2023 11:37:46 -0300 |
Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> On 20/1/23 19:48, Fabiano Rosas wrote:
>> The migration tests are currently broken for an aarch64 host because
>> the tests pass no 'machine' and 'cpu' options on the QEMU command
>> line. Most other architectures define a default value in QEMU for
>> these options, but arm does not.
>
> There was some discussions around that in the past:
> https://lore.kernel.org/qemu-devel/20190621153806.13489-1-wainersm@redhat.com/
> https://lore.kernel.org/qemu-devel/CAFEAcA9NBu+L4wHfkLTv93wy90wjnV05EZ12PT6PmLjdZ5h_YA@mail.gmail.com/
There's more than one topic being discussed, specially in this last
thread, but here's my two cents.
About defaults: It's probably best to be explicit in tests. And if we
wanted, have a separate test to make sure the lack of an option still
does what it's expected, either outputting a message or behaving the
same as the explicit version.
About host architecture-specific tests: Unless we're talking about KVM,
I see no point. Having to change hosts to test agnostic features makes
no sense (the migration test is one example).
About generic tests: If a feature is required to behave the same for all
architectures/machines/cpus then sure. But most low level stuff would be
quite dependent on specifics.
>> Add these options to the test class in case the test is being executed
>> in an aarch64 host.
>
> I'm not sure what we are aiming to test here.
>
> Migration in general? If so, any random machine should work.
> By hardcoding the 'virt' machine, at least this test is reproducible.
Yeah, I cannot say for sure there isn't some machine property that gets
transferred during migration. It seemed more conservative to define a
specific one.
> I'd rather fix that generically as "if a test requires a default
> machine and the target doesn't provide any default, then SKIP the
> test". Then adding machine-specific tests. Can be done on top, so
I agree, but the only tests that should *require* a default are the ones
that test the command line parsing or adjacent features. We could always
test "-machine foo" and then separately test that the lack of a machine
option still gives the Foo machine.
The fact that we sometimes use defaults to be able to have the same-ish
command line for every case is more of a limitation of our testing
infrastructure in my opinion.
- [RFC PATCH v5 2/9] target/arm: move cpu_tcg to tcg/cpu32.c, (continued)
- [RFC PATCH v5 2/9] target/arm: move cpu_tcg to tcg/cpu32.c, Fabiano Rosas, 2023/01/20
- [RFC PATCH v5 1/9] target/arm: Move 64-bit TCG CPUs into tcg/, Fabiano Rosas, 2023/01/20
- [RFC PATCH v5 6/9] tests/tcg: Do not build/run TCG tests if TCG is disabled, Fabiano Rosas, 2023/01/20
- [RFC PATCH v5 3/9] target/arm: Use "max" as default cpu for the virt machine with KVM, Fabiano Rosas, 2023/01/20
- [RFC PATCH v5 4/9] tests/qtest: arm-cpu-features: Match tests to required accelerators, Fabiano Rosas, 2023/01/20
- [RFC PATCH v5 5/9] tests/qtest: Restrict tpm-tis-devices-{swtpm}-test to CONFIG_TCG, Fabiano Rosas, 2023/01/20
- [RFC PATCH v5 7/9] target/avocado: Pass parameters to migration test on aarch64, Fabiano Rosas, 2023/01/20
[RFC PATCH v5 8/9] arm/Kconfig: Always select SEMIHOSTING when TCG is present, Fabiano Rosas, 2023/01/20
[RFC PATCH v5 9/9] arm/Kconfig: Do not build TCG-only boards on a KVM-only build, Fabiano Rosas, 2023/01/20