Jonathan Cameron via <qemu-devel@nongnu.org> writes:
> On Wed, 30 Jul 2025 17:52:45 -0300
> Fabiano Rosas <faro...@suse.de> wrote:
>
>> Don't use the 'max' cpu for migration testing of aarch64. That cpu
>> does not provide a stable set of features and is expected to break
>> migration from time to time.
>
> Whilst I can see the motivation, doesn't this leave us with a lack of
> converage for new CPU features that are currently only in max?
It does. That's an interesting aspect. It's better to make sure the new
features come with at least some basic migration support off the gate.
I'll add a patch to this series leaving one of the tests with -cpu
max. That should be enough to cover this scenario.
Thanks
>>
>> Signed-off-by: Fabiano Rosas <faro...@suse.de>
>> ---
>> tests/qtest/migration/framework.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/qtest/migration/framework.c
>> b/tests/qtest/migration/framework.c
>> index f09365d122..6d980b6b51 100644
>> --- a/tests/qtest/migration/framework.c
>> +++ b/tests/qtest/migration/framework.c
>> @@ -317,7 +317,7 @@ int migrate_start(QTestState **from, QTestState **to,
>> const char *uri,
>> memory_size = "150M";
>> machine_alias = "virt";
>> machine_opts = "gic-version=3";
>> - arch_opts = g_strdup_printf("-cpu max -kernel %s", bootpath);
>> + arch_opts = g_strdup_printf("-cpu neoverse-n1 -kernel %s",
>> bootpath);
>> start_address = ARM_TEST_MEM_START;
>> end_address = ARM_TEST_MEM_END;
>> } else {
