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

[Daniel Henrique Barboza]

On 7/10/23 15:13, Palmer Dabbelt wrote:
> On Mon, 10 Jul 2023 10:53:12 PDT (-0700), dbarboza@ventanamicro.com 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?
>
> Pretty sure it's just been a somewhat arbitrary decision, with stuff that's 
> likely to be used being enabled when it's added.
>
> > 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;
>
> IMO it's the right idea in spirit, but there's a handful of conflicting 
> extensions -- mostly vendor stuff, but even some of the standard ones have 
> conflicting encodings.  So I think there's likely to be some decisions to make 
> there, but when there's conflicts there's usually also one called out as being 
> aimed at microcontroller-class systems so there should be a natural choice.
>
> > 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;
>
> Would we also make incompatible extensions forbidden in the profile CPUs?

I think we can allow those as long as they're not in conflict with mandatory
profile extensions (not sure if there's a case of that).

> If we add the 23 profiles, we should probably also add some other bases. We've 
> got a defacto base in Linux that's rv{32,64}ima (plus some cruft as things have 
> drifted around), I think there's also some interest in the 22 profiles.

rv32/64ima would be the base of the minimal generic CPUs I proposed below.

> > 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".
>
> Have a "minimum CPU required to boot Linux" option seems reasonable. Most users 
> will probably want at least FD and C, though, so maybe we want something like that as 
> well?

I don't mind making the minimal CPU be rv32/64imafdc.

> > 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.
>
> IMO we still want to keep the ability to turn on/off extensions, the profiles 
> are a long way from being concrete and we'll still have a lot of systems 
> floating around that don't line up with them.  Being able to test those 
> configurations in QEMU is a huge benefit for users, even if it's a headache to 
> keep around all the options.

Absolutely. What I meant is that, today, rv64 has a default set of extensions
that seems arbitrary. It would be good to have more predictability, i.e. have
a fixed set of extensions (like rv64imafdc) that users can use as a base to
enable/disable extensions.

The same thing can be done with profiles. I don't see a reason to forbid users
to do this:

'-cpu rv64,profile=rva23S64,icbom=false'

Meaning "I want the rva23S64 profile without Zicbom". The user should be aware 
that
Zicbom is mandatory for the profile, but since it's being explicitly disabled 
in the
command line, we can comply. This can be used for debug/development purposes or
the user is doing something silly. As long as it's explicit in the command line
it's fine.


Thanks,

Daniel


> > 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