From: Gavin Shan <gshan@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
eduardo@habkost.net, marcel.apfelbaum@gmail.com,
philmd@linaro.org, wangyanan55@huawei.com, shan.gavin@gmail.com
Subject: Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation
Date: Thu, 13 Jul 2023 22:42:57 +1000 [thread overview]
Message-ID: <08a313fd-ddf8-538d-df51-03e28aee0d97@redhat.com> (raw)
In-Reply-To: <CAFEAcA8197FCwfNZrnxfO-87RveOko0Ju-KcTJOEi0vfjVtDKg@mail.gmail.com>
Hi Peter,
On 7/13/23 21:44, Peter Maydell wrote:
> On Thu, 13 Jul 2023 at 06:45, Gavin Shan <gshan@redhat.com> wrote:
>>
>> There is a generic CPU type invalidation in machine_run_board_init()
>> and we needn't a same and private invalidation for hw/arm/virt machines.
>> This series intends to use the generic CPU type invalidation on the
>> hw/arm/virt machines.
>>
>> PATCH[1] factors the CPU type invalidation logic in machine_run_board_init()
>> to a helper validate_cpu_type().
>> PATCH[2] uses the generic CPU type invalidation for hw/arm/virt machines
>> PATCH[3] support "host-arm-cpu" CPU type only when KVM or HVF is visible
>>
>> Testing
>> =======
>>
>> With the following command lines, the output messages are varied before
>> and after the series is applied.
>>
>> /home/gshan/sandbox/src/qemu/main/build/qemu-system-aarch64 \
>> -accel tcg -machine virt,gic-version=3,nvdimm=on \
>> -cpu cortex-a8 -smp maxcpus=2,cpus=1 \
>> :
>>
>> Before the series is applied:
>>
>> qemu-system-aarch64: mach-virt: CPU type cortex-a8-arm-cpu not supported
>>
>> After the series is applied:
>>
>> qemu-system-aarch64: Invalid CPU type: cortex-a8-arm-cpu
>> The valid types are: cortex-a7-arm-cpu, cortex-a15-arm-cpu, \
>> cortex-a35-arm-cpu, cortex-a55-arm-cpu, cortex-a72-arm-cpu, \
>> cortex-a76-arm-cpu, a64fx-arm-cpu, neoverse-n1-arm-cpu, \
>> neoverse-v1-arm-cpu, cortex-a53-arm-cpu, cortex-a57-arm-cpu, \
>> max-arm-cpu
>
> I see this isn't a change in this patch, but given that
> what the user specifies is not "cortex-a8-arm-cpu" but
> "cortex-a8", why do we include the "-arm-cpu" suffix in
> the error messages? It's not valid syntax to say
> "-cpu cortex-a8-arm-cpu", so it's a bit misleading...
>
Good point. Right, the complete CPU type names are provided by board (hw/arm/virt).
The compelte CPU type names are used in hw/core/machine.c to search the object
class. In the error messages in the same source file, the complete CPU type names
are also used. Actually, we need 'internal' names like 'cortex-a8' to be shown in the
error messages.
For the solution, I've suggested to split the MachineClass::valid_cpu_types to
two fields (valid_cpu_types and valid_cpu_type_suffix). Their combination is
the complete CPU type name and 'valid_cpu_types[i]' corresponds to the 'internal'
name, to be used in the error messages. Please take a look on that thread and reply
to it.
Thanks,
Gavin
prev parent reply other threads:[~2023-07-13 12:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 5:44 [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation Gavin Shan
2023-07-13 5:45 ` [PATCH 1/3] machine: Factor CPU type invalidation out into helper Gavin Shan
2023-07-14 12:07 ` Igor Mammedov
2023-07-18 6:11 ` Gavin Shan
2023-07-24 14:39 ` Igor Mammedov
2023-07-13 5:45 ` [PATCH 2/3] hw/arm/virt: Use generic CPU type invalidation Gavin Shan
2023-07-14 11:59 ` Igor Mammedov
2023-07-18 6:17 ` Gavin Shan
2023-07-13 5:45 ` [PATCH 3/3] hw/arm/virt: Support host CPU type only when KVM or HVF is configured Gavin Shan
2023-07-13 12:46 ` Cornelia Huck
2023-07-13 13:16 ` Gavin Shan
2023-07-13 11:44 ` [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation Peter Maydell
2023-07-13 11:52 ` Marcin Juszkiewicz
2023-07-13 11:59 ` Peter Maydell
2023-07-14 11:50 ` Igor Mammedov
2023-07-14 12:56 ` Peter Maydell
2023-07-17 12:44 ` Igor Mammedov
2023-07-18 10:31 ` Gavin Shan
2023-07-24 15:06 ` Igor Mammedov
2023-07-24 15:14 ` Peter Maydell
2023-07-25 6:46 ` Igor Mammedov
2023-07-13 12:34 ` Gavin Shan
2023-07-13 12:44 ` Marcin Juszkiewicz
2023-07-13 13:00 ` Gavin Shan
2023-07-13 16:29 ` Philippe Mathieu-Daudé
2023-07-14 0:51 ` Gavin Shan
2023-07-14 9:14 ` Gavin Shan
2023-07-13 19:27 ` Richard Henderson
2023-07-14 0:54 ` Gavin Shan
2023-07-13 12:42 ` Gavin Shan [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=08a313fd-ddf8-538d-df51-03e28aee0d97@redhat.com \
--to=gshan@redhat.com \
--cc=eduardo@habkost.net \
--cc=marcel.apfelbaum@gmail.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=shan.gavin@gmail.com \
--cc=wangyanan55@huawei.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.