On Wed, Jul 12, 2023 at 05:30:41PM -0300, Daniel Henrique Barboza wrote: > On 7/12/23 16:22, Conor Dooley wrote: > > On Wed, Jul 12, 2023 at 04:01:48PM -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. > > > > > > Signed-off-by: Daniel Henrique Barboza <dbarb...@ventanamicro.com> > > > > This seems like it will be super helpful for CI stuff etc, thanks for > > doing it. > > And Linux actually boots on it, which was remarkable to see. I was expecting > something > to blow up I guess. > > This is the riscv,isa DT generated: > > # cat /proc/device-tree/cpus/cpu@0/riscv,isa > rv64imafdch_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#
Of which an upstream Linux kernel, building using something close to defconfig, accepts only rv64imafdch_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sscofpmf_sstc_svinval_svnapot_svpbmt so the set of possible things that break could break it has been reduced somewhat. btw, I noticed that the default marchid/mimpid have changed. Previously I used to see something like: processor : 15 hart : 15 isa : rv64imafdcvh_zicbom_zicboz_zicntr_zicsr_zifencei_zihintpause_zihpm_zba_zbb_zbs_sscofpmf_sstc mmu : sv57 mvendorid : 0x0 marchid : 0x80032 mimpid : 0x80032 in /proc/cpuinfo, but "now" I see 0x0 for marchid & mimpid. Is this change to the default behaviour intentional? I saw "now" in "s because I applied your patches on top of Alistair's next branch, which contains the changes to m*id stuff. Cheers, Conor.
signature.asc
Description: PGP signature