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.