Re: [RFC PATCH v5 7/9] target/avocado: Pass parameters to migration test on aarch64

[Fabiano Rosas <farosas@suse.de>]

Philippe Mathieu-Daudé <philmd@linaro.org> writes:

> On 23/1/23 15:37, Fabiano Rosas wrote:
>> 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.
>
> Why did you choose 'virt' and not 'xlnx-versal-virt' or 'sbsa-ref'?

It is the only one guaranteed to be present with both TCG and KVM.