From: Fabiano Rosas <farosas@suse.de>
To: Claudio Fontana <cfontana@suse.de>,
Peter Maydell <peter.maydell@linaro.org>
Cc: "Thomas Huth" <thuth@redhat.com>,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Alexander Graf" <agraf@csgraf.de>,
"Laurent Vivier" <lvivier@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [RFC PATCH v2 13/19] tests: do not run test-hmp on all machines for ARM KVM-only
Date: Wed, 11 Jan 2023 09:36:43 -0300 [thread overview]
Message-ID: <87fschcko4.fsf@suse.de> (raw)
In-Reply-To: <9fb63a5d-d839-016d-b0a8-4151b6d6946c@suse.de>
Claudio Fontana <cfontana@suse.de> writes:
> On 1/10/23 15:02, Peter Maydell wrote:
>> On Tue, 10 Jan 2023 at 13:36, Fabiano Rosas <farosas@suse.de> wrote:
>>>
>>> Peter Maydell <peter.maydell@linaro.org> writes:
>>>
>>>> On Tue, 10 Jan 2023 at 13:00, Fabiano Rosas <farosas@suse.de> wrote:
>>>>>
>>>>> Thomas Huth <thuth@redhat.com> writes:
>>>>>
>>>>>> On 09/01/2023 23.42, Fabiano Rosas wrote:
>>>>>>> From: Claudio Fontana <cfontana@suse.de>
>>>>>>>
>>>>>>> on ARM we currently list and build all machines, even when
>>>>>>> building KVM-only, without TCG.
>>>>>>>
>>>>>>> Until we fix this (and we only list and build machines that are
>>>>>>> compatible with KVM), only test specifically using the "virt"
>>>>>>> machine in this case.
>>>>>>
>>>>>> Why don't you fix it immediately? ...
>>>>>
>>>>> My idea was to have in this series the minimum to unbreak the
>>>>> --disable-tcg build and later bring the rest of the changes
>>>>> incrementally.
>>>>
>>>> This test is basically checking "all the machines should
>>>> work". That's an important invariant to maintain, so
>>>> I don't think we should just skip it for Arm targets.
>>>
>>> But what does "all machines" mean in a no-TCG build? The original intent
>>> of the patch was that only 'virt' should be present and therefore the
>>> only one tested.
>>
>> It means "every machine the user can create". If the
>> machine can't run then either we shouldn't compile it
>> in, or else we should be compiling in enough extra stuff
>> to allow it to work.
>>
>> -- PMM
>
> Hi,
>
> once upon a time there was a series by Philippe to accomplish that (KConfig) right?
Is this it?
https://www.mail-archive.com/qemu-devel@nongnu.org/msg777719.html
I have now moved the cpus into the tcg directory:
# ./qemu-system-aarch64 -cpu ?
Available CPUs:
a64fx
cortex-a35
cortex-a53
cortex-a55
cortex-a57
cortex-a72
cortex-a76
host
max
neoverse-n1
What remains is changing the Kconfig to not bring all the
machines. Nowadays for KVM is the 'virt' machine the only one we use? I
did some tests yesterday by keeping only CONFIG_ARM_VIRT and was left
with this:
# ./qemu-system-aarch64 -machine ?
Supported machines are:
none empty machine
virt-2.10 QEMU 2.10 ARM Virtual Machine
virt-2.11 QEMU 2.11 ARM Virtual Machine
virt-2.12 QEMU 2.12 ARM Virtual Machine
virt-2.6 QEMU 2.6 ARM Virtual Machine
virt-2.7 QEMU 2.7 ARM Virtual Machine
virt-2.8 QEMU 2.8 ARM Virtual Machine
virt-2.9 QEMU 2.9 ARM Virtual Machine
virt-3.0 QEMU 3.0 ARM Virtual Machine
virt-3.1 QEMU 3.1 ARM Virtual Machine
virt-4.0 QEMU 4.0 ARM Virtual Machine
virt-4.1 QEMU 4.1 ARM Virtual Machine
virt-4.2 QEMU 4.2 ARM Virtual Machine
virt-5.0 QEMU 5.0 ARM Virtual Machine
virt-5.1 QEMU 5.1 ARM Virtual Machine
virt-5.2 QEMU 5.2 ARM Virtual Machine
virt-6.0 QEMU 6.0 ARM Virtual Machine
virt-6.1 QEMU 6.1 ARM Virtual Machine
virt-6.2 QEMU 6.2 ARM Virtual Machine
virt-7.0 QEMU 7.0 ARM Virtual Machine
virt-7.1 QEMU 7.1 ARM Virtual Machine
virt-7.2 QEMU 7.2 ARM Virtual Machine
virt QEMU 8.0 ARM Virtual Machine (alias of virt-8.0)
virt-8.0 QEMU 8.0 ARM Virtual Machine
x-remote Experimental remote machine
But qtest dislikes that even more. I need to figure out why.
The approach of that series seems interesting, moving CONFIG_FOO=y from
default.mak into Kconfig as 'default y if TCG'. Maybe that will yield
better results, I'll try to follow that route.
next prev parent reply other threads:[~2023-01-11 12:37 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 22:42 [RFC PATCH v2 00/19] target/arm: Allow CONFIG_TCG=n builds Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 01/19] target/arm: rename handle_semihosting to tcg_handle_semihosting Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 02/19] target/arm: wrap psci call with tcg_enabled Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 03/19] target/arm: wrap call to aarch64_sve_change_el in tcg_enabled() Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 04/19] target/arm: Move PC alignment check Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 05/19] target/arm: Move cpregs code into cpregs.c Fabiano Rosas
2023-01-10 5:37 ` Richard Henderson
2023-01-09 22:42 ` [RFC PATCH v2 06/19] target/arm: Move define_debug_regs() to cpregs.c Fabiano Rosas
2023-01-10 5:41 ` Richard Henderson
2023-01-09 22:42 ` [RFC PATCH v2 07/19] target/arm: Move helper_set_pstate_* into cpregs.c Fabiano Rosas
2023-01-10 5:52 ` Richard Henderson
2023-01-10 13:19 ` Fabiano Rosas
2023-01-10 14:00 ` Peter Maydell
2023-01-11 3:48 ` Richard Henderson
2023-01-09 22:42 ` [RFC PATCH v2 08/19] target/arm: move translate modules to tcg/ Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 09/19] target/arm: move helpers " Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 10/19] target/arm: Move psci.c into the tcg directory Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 11/19] target/arm: Wrap arm_rebuild_hflags calls with tcg_enabled Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 12/19] target/arm: Move hflags code into the tcg directory Fabiano Rosas
2023-01-11 20:29 ` Richard Henderson
2023-01-09 22:42 ` [RFC PATCH v2 13/19] tests: do not run test-hmp on all machines for ARM KVM-only Fabiano Rosas
2023-01-10 8:02 ` Thomas Huth
2023-01-10 13:00 ` Fabiano Rosas
2023-01-10 13:06 ` Peter Maydell
2023-01-10 13:36 ` Fabiano Rosas
2023-01-10 14:02 ` Peter Maydell
2023-01-11 12:08 ` Claudio Fontana
2023-01-11 12:22 ` Thomas Huth
2023-01-11 12:36 ` Fabiano Rosas [this message]
2023-01-11 20:30 ` Richard Henderson
2023-01-12 14:49 ` Fabiano Rosas
2023-01-12 14:55 ` Peter Maydell
2023-01-09 22:42 ` [RFC PATCH v2 14/19] tests: do not run qom-test " Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 15/19] tests: device-introspect-test: cope with ARM TCG-only devices Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 16/19] tests/tcg: Do not build/run TCG tests if TCG is disabled Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 17/19] target/arm: Move regime_using_lpae_format into internal.h Fabiano Rosas
2023-01-11 5:46 ` Richard Henderson
2023-01-09 22:42 ` [RFC PATCH v2 18/19] cpu-defs.h: Expose CPUTLBEntryFull to non-TCG code Fabiano Rosas
2023-01-09 22:42 ` [RFC PATCH v2 19/19] target/arm: don't access TCG code when debugging with KVM 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=87fschcko4.fsf@suse.de \
--to=farosas@suse.de \
--cc=agraf@csgraf.de \
--cc=alex.bennee@linaro.org \
--cc=cfontana@suse.de \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=lvivier@redhat.com \
--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=thuth@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).