From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
To: Fabiano Rosas <farosas@suse.de>, qemu-devel@nongnu.org
Cc: "Cleber Rosa" <crosa@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Beraldo Leal" <bleal@redhat.com>
Subject: Re: [PATCH 3/3] avocado_qemu: add AVOCADO_DEFAULT_MACHINE
Date: Wed, 18 Jan 2023 14:21:16 -0300 [thread overview]
Message-ID: <005bad40-129c-7785-8fa3-c8a4eaee9da6@ventanamicro.com> (raw)
In-Reply-To: <874jsndf2g.fsf@suse.de>
On 1/18/23 12:42, Fabiano Rosas wrote:
> Daniel Henrique Barboza <dbarboza@ventanamicro.com> writes:
>
>> Allow users to control which machine to use in tests where no particular
>> machine is specified. This is a good way to run tests in a machine
>> that's not the arch default, e.g. for qemu-system-x86_64 tests can be
>> run using a machine other than pc-i440fx.
>>
>> This env var has greater effect when used together with the recently
>> added AVOCADO_DEFAULT_ARCH, allowing full control of what the tests
>> should use if no default arch/machine is given. In this example, a
>> check-avocado run will use the RISC-V 'virt' machine if no default
>> arch/machine is set:
>>
>> AVOCADO_DEFAULT_ARCH=riscv64 AVOCADO_DEFAULT_MACHINE=virt make check-avocado
>>
>> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
>> ---
>> docs/devel/testing.rst | 8 +++++---
>> tests/avocado/avocado_qemu/__init__.py | 3 +++
>> 2 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
>> index 95d0a3e626..128b6ae964 100644
>> --- a/docs/devel/testing.rst
>> +++ b/docs/devel/testing.rst
>> @@ -1178,9 +1178,11 @@ The machine type that will be set to all QEMUMachine instances created
>> by the test.
>>
>> The ``machine`` attribute will be set to the test parameter of the same
>> -name. If one is not given explicitly, it will either be set to
>> -``None``, or, if the test is tagged with one (and only one)
>> -``:avocado: tags=machine:VALUE`` tag, it will be set to ``VALUE``.
>> +name. If one is not given explicitly, an env variable
>> +AVOCADO_DEFAULT_MACHINE can be used as default value if set. Otherwise
>> +it will either be set to ``None``, or, if the test is tagged with one
>> +(and only one) ``:avocado: tags=machine:VALUE`` tag, it will be set to
>> +``VALUE``.
>>
>> qemu_bin
>> ''''''''
>> diff --git a/tests/avocado/avocado_qemu/__init__.py b/tests/avocado/avocado_qemu/__init__.py
>> index bc42985cbb..75eaaa9265 100644
>> --- a/tests/avocado/avocado_qemu/__init__.py
>> +++ b/tests/avocado/avocado_qemu/__init__.py
>> @@ -282,6 +282,9 @@ def setUp(self):
>> self.machine = self.params.get('machine',
>> default=self._get_unique_tag_val('machine'))
>>
> Would it work for you to replicate the AVOCADO_CMDLINE_TAGS behavior?
>
> In Makefile.include:
>
> ifdef AVOCADO_PARAMS
> AVOCADO_CMDLINE_PARAMS=$(addprefix -p , $(AVOCADO_PARAMS))
> endif
>
> make V=1 check-avocado AVOCADO_PARAMS=machine=foo AVOCADO_TESTS=../tests/avocado/migration.py
>
> Results in:
>
> ./qemu-system-x86_64 -display none -vga none ... -machine foo
This doesn't work as is (tested with no patches applied, only added AVOCADO_PARAMS in
Makefile.include).
At this moment it seems that there is no way of changing Avocado internal behavior
by using command line parameters/tags.
Thanks,
Daniel
prev parent reply other threads:[~2023-01-18 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 12:43 [PATCH 0/3] avocado_qemu: allow cross-arch tests Daniel Henrique Barboza
2023-01-18 12:43 ` [PATCH 1/3] avocado_qemu: enhance CANCEL message in QemuBaseTest:setUp() Daniel Henrique Barboza
2023-01-18 15:24 ` Fabiano Rosas
2023-01-18 12:43 ` [PATCH 2/3] avocado_qemu: add AVOCADO_DEFAULT_ARCH for cross-arch tests Daniel Henrique Barboza
2023-01-18 15:23 ` Fabiano Rosas
2023-01-18 16:06 ` Daniel Henrique Barboza
2023-01-18 12:43 ` [PATCH 3/3] avocado_qemu: add AVOCADO_DEFAULT_MACHINE Daniel Henrique Barboza
2023-01-18 15:42 ` Fabiano Rosas
2023-01-18 17:21 ` Daniel Henrique Barboza [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=005bad40-129c-7785-8fa3-c8a4eaee9da6@ventanamicro.com \
--to=dbarboza@ventanamicro.com \
--cc=bleal@redhat.com \
--cc=crosa@redhat.com \
--cc=farosas@suse.de \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.