[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-8.2 v5 09/11] target/riscv: add 'max' CPU type
From: |
Conor Dooley |
Subject: |
Re: [PATCH for-8.2 v5 09/11] target/riscv: add 'max' CPU type |
Date: |
Thu, 27 Jul 2023 15:16:12 +0100 |
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.
> 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?
signature.asc
Description: PGP signature
- Re: [PATCH for-8.2 v5 04/11] target/riscv/cpu.c: del DEFINE_PROP_END_OF_LIST() from riscv_cpu_extensions, (continued)
- [PATCH for-8.2 v5 06/11] target/riscv/cpu.c: split non-ratified exts from riscv_cpu_extensions[], Daniel Henrique Barboza, 2023/07/20
- [PATCH for-8.2 v5 07/11] target/riscv/cpu.c: add ADD_CPU_QDEV_PROPERTIES_ARRAY() macro, Daniel Henrique Barboza, 2023/07/20
- [PATCH for-8.2 v5 05/11] target/riscv/cpu.c: split vendor exts from riscv_cpu_extensions[], Daniel Henrique Barboza, 2023/07/20
- [PATCH for-8.2 v5 08/11] target/riscv/cpu.c: add ADD_UNAVAIL_KVM_PROP_ARRAY() macro, Daniel Henrique Barboza, 2023/07/20
- [PATCH for-8.2 v5 11/11] target/riscv: deprecate the 'any' CPU type, Daniel Henrique Barboza, 2023/07/20
- [PATCH for-8.2 v5 09/11] target/riscv: add 'max' CPU type, Daniel Henrique Barboza, 2023/07/20
[PATCH for-8.2 v5 10/11] avocado, risc-v: add opensbi tests for 'max' CPU, Daniel Henrique Barboza, 2023/07/20