Re: [PATCH for-8.2 v5 09/11] target/riscv: add 'max' CPU type

[Daniel Henrique Barboza]

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.

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.


Thanks,

Daniel




> Cheers,
> Conor.