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

[Conor Dooley]

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