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

[Andrea Bolognani]

Sorry for being late to the party, and I see that you're already a
few versions in with the actual patches. Hopefully nothing I write
here is going to be too disruptive of the work you've already done :)

On Mon, Jul 10, 2023 at 02:53:12PM -0300, Daniel Henrique Barboza wrote:
> 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;

Yes please. At least for TCG, this is pretty much a no-brainer and
what most people will probably want to use.

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

IIUC profiles are basically shorthands for well-defined sets of
extensions. The idea definitely sounds valuable, but I wonder how
we'd expose it from the libvirt XML.

My question would be, why should this be -cpu rv64,profile=rva23U64
instead of just -cpu rva23U64? "Base ISA plus a number of extensions"
pretty much sounds like a named CPU model to me, but I'm sure there
is more to it :)

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

Can't we make the generic CPUs really bare-bones instead?

Not sure what exactly that would look like, but as long as you can
enable specific extensions explicitly I don't see the advantage in
targeting a specific use case (boot Linux), no matter how popular,
instead of providing useful building blocks for custom behavior.

The use case of booting Linux, and really most RISC-V operating
systems, should already be well served by -cpu max for TCG and -cpu
host for KVM.

-- 
Andrea Bolognani / Red Hat / Virtualization