Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support

[Andrew Jones]

On Mon, Jul 10, 2023 at 02:53:12PM -0300, Daniel Henrique Barboza wrote:
> Hi,
> 
> We don't have a 'max' cpu type in riscv32 and riscv64. This is a special,
> fictional CPU type that has all possible extensions enabled. It can be
> either an alias for a real CPU or a new CPU type. It's used by tooling
> such as libvirt for capabilities probing.
> 
> Well, in our case it can't be an alias because we don't have any CPU type
> that enables all extensions. Which brings me to my first question:
> what's the criteria for marking a certain extension default true/false
> in rv32/rv64/rv128?
> 
> E.g. this is the riscv,isa DT for rv64:
> 
> rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu
> 
> It has a lot of extensions but it's missing some common ones like svinval
> and smstateen.
> 
> We can add/remove some extensions from these generic CPUs, document it
> and be done with it. I want to propose a different design though:
> 
> 1 - introduce the 'max' CPU. I guess we'll need some prep work in how
> the extensions are being declared/stored in the code. I'll work on
> it;
> 
> 2 - introduce rva23U64/rva23S64. I would like to add a new 'profile' option
> for generic CPUs, with '-cpu rv64,profile=rva23U64' enabling a whole set
> of extensions. We would also support enabling optional profile extensions.
> Yes, we don't have all the profile extensions available yet (neither does
> the kernel AFAIK) but nothing is stopping us from adding the base
> framework;
> 
> 3 - reduce the generic CPUs up to the minimum required to boot Linux.
> Yes, a rather arbitrary criteria, but Linux is the most common OS used
> by RISC-V QEMU currently so we'll go with what most people are using.
> This would reduce rv64 to "rv64ima".
> 
> The end result is that we would have a max extensions CPU, a barebones
> generic CPU that can be fully customizable from the ground up, and
> a profile option to allow users to boost the generic CPUs with a
> set of extensions. We will avoid having to deal with generic CPUs having
> an (apparently) arbitrary set of extensions.
> 
> I don't think we'll have too much opposition on adding (1) so I'll get
> on it. I really would like to hear about (2) and (3). (3) will break
> users that are using rv64 while counting with that whole set of extensions
> that are being enabled by default, but this is why we're going to add
> (2) first.

Everything sounds good to me, once we've agreed on a proper "minimal
Linux supporting" base to map rv64 to. One thing I would change, though,
is rather than have an enum property 'profile', I'd create booleans
rva22S64, rva23S64, ... Keeping cpu properties boolean simplifies
introspection. And, when we have mutually exclusive profiles, QEMU can
error out at cpu feature finalize time, but, when they're not mutually
exclusive, then why not allow more than one to be selected.

Thanks,
drew