All of lore.kernel.org
 help / color / mirror / Atom feed
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?
> 


  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 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.