tests/avocado: Update LoongArch bios file

The VM uses old bios to boot up only 1 cpu, causing the test case to fail.
Update the bios to solve this problem.

Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Song Gao <gaosong@loongson.cn>
---
 tests/avocado/machine_loongarch.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On Thu, 30 May 2024 at 13:59, Song Gao <gaosong@loongson.cn> wrote:
>
> The VM uses old bios to boot up only 1 cpu, causing the test case to fail.
> Update the bios to solve this problem.
>
> Reported-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Song Gao <gaosong@loongson.cn>
> ---
>  tests/avocado/machine_loongarch.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/avocado/machine_loongarch.py b/tests/avocado/machine_loongarch.py
> index 7d8a3c1fa5..12cc5ed814 100644
> --- a/tests/avocado/machine_loongarch.py
> +++ b/tests/avocado/machine_loongarch.py
> @@ -38,7 +38,7 @@ def test_loongarch64_devices(self):
>
>          bios_url = ('https://github.com/yangxiaojuan-loongson/qemu-binary/'
>                      'releases/download/binary-files/QEMU_EFI.fd')
> -        bios_hash = ('dfc1bfba4853cd763b9d392d0031827e8addbca8')
> +        bios_hash = ('f4d0966b5117d4cd82327c050dd668741046be69')

This doesn't look right -- the file has the same URL but a different
hash. This causes problems because the test suite on older
versions of QEMU (eg our stable branches) will still be using
this same URL but the old hash. So instead of running the test with
the old BIOS version as they should, they'll skip the test if Avocado
doesn't have the old file in its content cache.

Is it possible for this test to use a file which doesn't change
its contents arbitrarily? e.g. some fixed released version with
a version number. Then if we need to use a newer BIOS version
we can update both the bios_url and the bios_hash, and the
old stable branches will continue to use the old URL and hash
to download the old version they expect.

(I just got kind of confused by this because my local system
has a copy of the old asset in its avocado cache, so the
test case fails for me locally, but it didn't get caught by
the gitlab CI because the gitlab CI happened not to have cached
the asset.)

thanks
-- PMM

在 2024/6/3 下午11:58, Peter Maydell 写道:
> On Thu, 30 May 2024 at 13:59, Song Gao <gaosong@loongson.cn> wrote:
>> The VM uses old bios to boot up only 1 cpu, causing the test case to fail.
>> Update the bios to solve this problem.
>>
>> Reported-by: Thomas Huth <thuth@redhat.com>
>> Signed-off-by: Song Gao <gaosong@loongson.cn>
>> ---
>>   tests/avocado/machine_loongarch.py | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/avocado/machine_loongarch.py b/tests/avocado/machine_loongarch.py
>> index 7d8a3c1fa5..12cc5ed814 100644
>> --- a/tests/avocado/machine_loongarch.py
>> +++ b/tests/avocado/machine_loongarch.py
>> @@ -38,7 +38,7 @@ def test_loongarch64_devices(self):
>>
>>           bios_url = ('https://github.com/yangxiaojuan-loongson/qemu-binary/'
>>                       'releases/download/binary-files/QEMU_EFI.fd')
>> -        bios_hash = ('dfc1bfba4853cd763b9d392d0031827e8addbca8')
>> +        bios_hash = ('f4d0966b5117d4cd82327c050dd668741046be69')
> This doesn't look right -- the file has the same URL but a different
> hash. This causes problems because the test suite on older
> versions of QEMU (eg our stable branches) will still be using
> this same URL but the old hash. So instead of running the test with
> the old BIOS version as they should, they'll skip the test if Avocado
> doesn't have the old file in its content cache.
>
> Is it possible for this test to use a file which doesn't change
> its contents arbitrarily? e.g. some fixed released version with
> a version number. Then if we need to use a newer BIOS version
> we can update both the bios_url and the bios_hash, and the
> old stable branches will continue to use the old URL and hash
> to download the old version they expect.
Thanks  for your sugesstion.
I will send a patch to fix it,

Thanks.
Song Gao