From: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
To: Conor Dooley <conor@kernel.org>
Cc: qemu-devel@nongnu.org, qemu-riscv@nongnu.org,
alistair.francis@wdc.com, bmeng@tinylab.org,
liweiwei@iscas.ac.cn, zhiwei_liu@linux.alibaba.com,
palmer@rivosinc.com
Subject: Re: [PATCH for-8.2 v5 09/11] target/riscv: add 'max' CPU type
Date: Thu, 27 Jul 2023 11:19:15 -0300 [thread overview]
Message-ID: <06ff46d8-eb7a-d568-1f69-3255e5c8944b@ventanamicro.com> (raw)
In-Reply-To: <20230727-flashy-obsolete-7a1c81524429@spud>
On 7/27/23 11:16, Conor Dooley wrote:
> On Thu, Jul 27, 2023 at 11:12:34AM -0300, Daniel Henrique Barboza wrote:
>>
>>
>> On 7/27/23 10:59, Conor Dooley wrote:
>>> Hey Daniel,
>>>
>>> On Thu, Jul 20, 2023 at 02:19:31PM -0300, Daniel Henrique Barboza wrote:
>>>> The 'max' CPU type is used by tooling to determine what's the most
>>>> capable CPU a current QEMU version implements. Other archs such as ARM
>>>> implements this type. Let's add it to RISC-V.
>>>>
>>>> What we consider "most capable CPU" in this context are related to
>>>> ratified, non-vendor extensions. This means that we want the 'max' CPU
>>>> to enable all (possible) ratified extensions by default. The reasoning
>>>> behind this design is (1) vendor extensions can conflict with each other
>>>> and we won't play favorities deciding which one is default or not and
>>>> (2) non-ratified extensions are always prone to changes, not being
>>>> stable enough to be enabled by default.
>>>>
>>>> All this said, we're still not able to enable all ratified extensions
>>>> due to conflicts between them. Zfinx and all its dependencies aren't
>>>> enabled because of a conflict with RVF. zce, zcmp and zcmt are also
>>>> disabled due to RVD conflicts. When running with 64 bits we're also
>>>> disabling zcf.
>>>>
>>>> MISA bits RVG, RVJ and RVV are also being set manually since they're
>>>> default disabled.
>>>>
>>>> This is the resulting 'riscv,isa' DT for this new CPU:
>>>>
>>>> rv64imafdcvh_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_
>>>> zfh_zfhmin_zca_zcb_zcd_zba_zbb_zbc_zbkb_zbkc_zbkx_zbs_zk_zkn_zknd_
>>>> zkne_zknh_zkr_zks_zksed_zksh_zkt_zve32f_zve64f_zve64d_
>>>> smstateen_sscofpmf_sstc_svadu_svinval_svnapot_svpbmt
>>>>
>>>> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
>>>> Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn>
>>>
>>> I was giving this another go today, like so
>>> $(qemu) -smp 4 -M virt,aia=aplic,dumpdtb=qemu.dtb -cpu max -m 1G
>>> which lead to a few
>>> vector version is not specified, use the default value v1.0
>>> printed. Should the max cpu set a vector version w/o user input
>>> being required?
>>
>>
>> This isn't exclusive to the 'max' cpu code per se. It's the common RVV handling
>> code that is expecting users to inform which vector version they're going to
>> use every time we activate V.
>
> Yah, I figured it was not exclusive to it, but it seemed "thematic" for
> the max cpu to silently pick a reasonable default rather than complain.
Fair point. For the 'max' CPU it definitely makes sense to pick a good default
instead of nagging about it.
I'll send a new version. Thanks,
Daniel
>
>> I believe it's too late to change the command line handling to force users to pick
>> a vector version, so the second better approach is to silently default to v1.0
>> (or perhaps to the latest RVV version available) if the user didn't set anything.
>
> Honestly, I'm not sure why it warns at the moment. Seems like the
> default is what any reasonable person would expect, no?
>
next prev parent reply other threads:[~2023-07-27 14:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 17:19 [PATCH for-8.2 v5 00/11] riscv: add 'max' CPU, deprecate 'any' Daniel Henrique Barboza
2023-07-20 17:19 ` [PATCH for-8.2 v5 01/11] target/riscv/cpu.c: split CPU options from riscv_cpu_extensions[] Daniel Henrique Barboza
2023-07-21 1:15 ` Weiwei Li
2023-07-24 3:24 ` Alistair Francis
2023-07-20 17:19 ` [PATCH for-8.2 v5 02/11] target/riscv/cpu.c: skip 'bool' check when filtering KVM props Daniel Henrique Barboza
2023-07-20 17:19 ` [PATCH for-8.2 v5 03/11] target/riscv/cpu.c: split kvm prop handling to its own helper Daniel Henrique Barboza
2023-07-21 1:31 ` Weiwei Li
2023-07-20 17:19 ` [PATCH for-8.2 v5 04/11] target/riscv/cpu.c: del DEFINE_PROP_END_OF_LIST() from riscv_cpu_extensions Daniel Henrique Barboza
2023-07-21 1:33 ` Weiwei Li
2023-07-20 17:19 ` [PATCH for-8.2 v5 05/11] target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[] Daniel Henrique Barboza
2023-07-20 17:19 ` [PATCH for-8.2 v5 06/11] target/riscv/cpu.c: split non-ratified " Daniel Henrique Barboza
2023-07-20 17:19 ` [PATCH for-8.2 v5 07/11] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro Daniel Henrique Barboza
2023-07-20 17:19 ` [PATCH for-8.2 v5 08/11] target/riscv/cpu.c: add ADD_UNAVAIL_KVM_PROP_ARRAY() macro Daniel Henrique Barboza
2023-07-21 1:34 ` Weiwei Li
2023-07-20 17:19 ` [PATCH for-8.2 v5 09/11] target/riscv: add 'max' CPU type Daniel Henrique Barboza
2023-07-27 13:59 ` Conor Dooley
2023-07-27 14:12 ` Daniel Henrique Barboza
2023-07-27 14:16 ` Conor Dooley
2023-07-27 14:19 ` Daniel Henrique Barboza [this message]
2023-07-20 17:19 ` [PATCH for-8.2 v5 10/11] avocado, risc-v: add opensbi tests for 'max' CPU Daniel Henrique Barboza
2023-07-20 17:19 ` [PATCH for-8.2 v5 11/11] target/riscv: deprecate the 'any' CPU type Daniel Henrique Barboza
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=06ff46d8-eb7a-d568-1f69-3255e5c8944b@ventanamicro.com \
--to=dbarboza@ventanamicro.com \
--cc=alistair.francis@wdc.com \
--cc=bmeng@tinylab.org \
--cc=conor@kernel.org \
--cc=liweiwei@iscas.ac.cn \
--cc=palmer@rivosinc.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=zhiwei_liu@linux.alibaba.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).