From: Juan Quintela <quintela@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: "Fabiano Rosas" <farosas@suse.de>,
qemu-devel@nongnu.org,
"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com>,
qemu-arm@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Claudio Fontana" <cfontana@suse.de>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Alexander Graf" <agraf@csgraf.de>,
"Cornelia Huck" <cohuck@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>
Subject: Re: [RFC PATCH v5 7/9] target/avocado: Pass parameters to migration test on aarch64
Date: Wed, 01 Feb 2023 21:54:08 +0100 [thread overview]
Message-ID: <878rhhumxb.fsf@secure.mitica> (raw)
In-Reply-To: <3f577967-377f-aa6d-1c69-542988a26a26@linaro.org> ("Philippe Mathieu-Daudé"'s message of "Mon, 23 Jan 2023 16:29:37 +0100")
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> 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'?
>
> What does this test require? Any machine running KVM?
>
> Adding Juan and David for migration since I'm still confused trying
> to understand what we are trying to test here...
No clue really from my side either.
ARM machine types are a mystery. But on one hand:
- arm is a sane architecture when there is no default machine
learn x86, learn.
- I don't know either which one to use.
Later, Juan.
>>> I'd rather fix that generically as "if a test requires a default
>>> machine and the target doesn't provide any default, then SKIP the
>>> test". Then adding machine-specific tests. Can be done on top, so
>> I agree, but the only tests that should *require* a default are the
>> ones
>> that test the command line parsing or adjacent features. We could always
>> test "-machine foo" and then separately test that the lack of a machine
>> option still gives the Foo machine.
>> The fact that we sometimes use defaults to be able to have the
>> same-ish
>> command line for every case is more of a limitation of our testing
>> infrastructure in my opinion.
next prev parent reply other threads:[~2023-02-01 20:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 18:48 [RFC PATCH v5 0/9] target/arm: Allow CONFIG_TCG=n builds Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 1/9] target/arm: Move 64-bit TCG CPUs into tcg/ Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 2/9] target/arm: move cpu_tcg to tcg/cpu32.c Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 3/9] target/arm: Use "max" as default cpu for the virt machine with KVM Fabiano Rosas
2023-01-20 20:54 ` Richard Henderson
2023-01-23 8:10 ` Thomas Huth
2023-01-20 18:48 ` [RFC PATCH v5 4/9] tests/qtest: arm-cpu-features: Match tests to required accelerators Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 5/9] tests/qtest: Restrict tpm-tis-devices-{swtpm}-test to CONFIG_TCG Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 6/9] tests/tcg: Do not build/run TCG tests if TCG is disabled Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 7/9] target/avocado: Pass parameters to migration test on aarch64 Fabiano Rosas
2023-01-23 9:06 ` Philippe Mathieu-Daudé
2023-01-23 14:37 ` Fabiano Rosas
2023-01-23 15:29 ` Philippe Mathieu-Daudé
2023-01-23 17:26 ` Fabiano Rosas
2023-02-01 20:54 ` Juan Quintela [this message]
2023-01-20 18:48 ` [RFC PATCH v5 8/9] arm/Kconfig: Always select SEMIHOSTING when TCG is present Fabiano Rosas
2023-01-20 18:48 ` [RFC PATCH v5 9/9] arm/Kconfig: Do not build TCG-only boards on a KVM-only build Fabiano Rosas
2023-02-01 13:36 ` [RFC PATCH v5 0/9] target/arm: Allow CONFIG_TCG=n builds Fabiano Rosas
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=878rhhumxb.fsf@secure.mitica \
--to=quintela@redhat.com \
--cc=agraf@csgraf.de \
--cc=alex.bennee@linaro.org \
--cc=bleal@redhat.com \
--cc=cfontana@suse.de \
--cc=cohuck@redhat.com \
--cc=crosa@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=farosas@suse.de \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=wainersm@redhat.com \
/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.