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

[Daniel Henrique Barboza]

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.


Please comment. Andrea, feel free to give us libvirt/tooling insights.


Thanks,

Daniel