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. > 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.
