On 23/1/23 15:37, Fabiano Rosas wrote:
Philippe Mathieu-Daudé <phi...@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-waine...@redhat.com/
https://lore.kernel.org/qemu-devel/cafeaca9nbu+l4whfkltv93wy90wjnv05ez12pt6pmljdz5h...@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.
Why did you choose 'virt' and not 'xlnx-versal-virt' or 'sbsa-ref'?
What does this test require? Any machine running KVM?
Adding Juan and David for migration since I'm still confused trying
to understand what we are trying to test here...
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.
