qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests/acceptance: Test PMON with Loongson-3A1000 CPU


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH] tests/acceptance: Test PMON with Loongson-3A1000 CPU
Date: Tue, 19 Jan 2021 06:57:26 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

On 1/18/21 5:54 PM, Alex Bennée wrote:
> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
>> On 1/12/21 3:07 AM, Jiaxun Yang wrote:
>>> Test booting of PMON bootloader on loongson3-virt platform.
>>>
>>> $ (venv) AVOCADO_ALLOW_UNTRUSTED_CODE=1 \
>>>     avocado --show=app,console \
>>>       run -t machine:loongson3-virt tests/acceptance
>>> Fetching asset from 
>>> tests/acceptance/machine_mips_loongson3v.py:MipsLoongson3v.test_pmon_serial_console
>>> JOB ID     : 8e202b3727847c9104d0d3d6546ed225d35f6706
>>> JOB LOG    : 
>>> /home/flygoat/avocado/job-results/job-2021-01-12T10.02-8e202b3/job.log
>> ...
>>> console: This software may be redistributed under the BSD copyright.
>>> console: Copyright 2000-2002, Opsycon AB, Sweden.
>>> console: Copyright 2005, ICT CAS.
>>> console: CPU GODSON3 BogoMIPS: 1327
>>> PASS (3.89 s)
>>> RESULTS    : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
>>> CANCEL 0
>>> JOB TIME   : 4.38 s
>>>
>>> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>>> ---
>>>  MAINTAINERS                                 |  1 +
>>>  tests/acceptance/machine_mips_loongson3v.py | 39 +++++++++++++++++++++
>>>  2 files changed, 40 insertions(+)
>>>  create mode 100644 tests/acceptance/machine_mips_loongson3v.py
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 4be087b88e..f38882f997 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1164,6 +1164,7 @@ F: hw/intc/loongson_liointc.c
>>>  F: hw/mips/loongson3_bootp.c
>>>  F: hw/mips/loongson3_bootp.h
>>>  F: hw/mips/loongson3_virt.c
>>> +F: tests/acceptance/machine_mips_loongson3v.py
>>>  
>>>  Boston
>>>  M: Paul Burton <paulburton@kernel.org>
>>> diff --git a/tests/acceptance/machine_mips_loongson3v.py 
>>> b/tests/acceptance/machine_mips_loongson3v.py
>>> new file mode 100644
>>> index 0000000000..17a85de69f
>>> --- /dev/null
>>> +++ b/tests/acceptance/machine_mips_loongson3v.py
>>> @@ -0,0 +1,39 @@
>>> +# Functional tests for the Generic Loongson-3 Platform.
>>> +#
>>> +# Copyright (c) 2020 Philippe Mathieu-Daudé <f4bug@amsat.org>
>>
>> 2021 Jiaxun Yang <jiaxun.yang@flygoat.com>? :D

Jiaxun, if you agree I can update that line and queue your patch.

>>
>>> +#
>>> +# This work is licensed under the terms of the GNU GPL, version 2 or later.
>>> +# See the COPYING file in the top-level directory.
>>> +#
>>> +# SPDX-License-Identifier: GPL-2.0-or-later
>>> +
>>> +import os
>>> +import time
>>> +
>>> +from avocado import skipUnless
>>> +from avocado_qemu import Test
>>> +from avocado_qemu import wait_for_console_pattern
>>> +
>>> +class MipsLoongson3v(Test):
>>> +    @skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted 
>>> code')
>>
>> The source code is published [1], you provided reproducible
>> workflow [2] and a tag [3] with a public build artifacts [4],
>> so my understanding is this is "trustable" binary.
>>
>> Alex, would it be OK to add this test without the UNTRUSTED tag
>> (amending the links in the commit description)?
> 
> It's a subjective call. Having open source code is a minimum step to
> being "trusted" but really the trust is in the community that hosts the
> code. The upstream distros (e.g. Debian/Fedora) are trusted because
> people install their software on their desktops and basically give the
> software publisher root on their machines. There has to be a level of
> trust that the distros won't abuse that to steal information from their
> users.
> 
> I personally have no idea about the loongson community because it's not
> one I interact with so I have no idea what sort of place it is. Is it a
> code dump for semi-proprietary non-upstreamed kernels or is it a place
> that has a good development culture with a sane security process that is
> responsive to problems and moderately conservative with what they merge?
> 
> If you would trust your keys to a machine running this communities
> software then by all means treated it as a trusted source.

Subjective call understood :)

Thanks for your clear explanation,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]