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 <dbarb...@ventanamicro.com> > > > Reviewed-by: Weiwei Li <liwei...@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
