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

[Daniel Henrique Barboza <dbarboza@ventanamicro.com>]

On 7/27/23 10:28, Andrea Bolognani wrote:
> 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 :)

We just finished warming up. National anthem starting in a few seconds.
Whole match ahead of us yet :P

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

I was thinking about adding them like CPU features, maybe? Like it is
already done for hyperv, gic, sev and so on. So we would have, e.g.:

<features>
   <profile>rva23U64</profile>
</features>


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

We can do what makes sense since it's a virtual CPU model anyways.

The advantage of implementing profiles using a new 'profile' flag instead
of using a new CPU model is that we can pile up profiles on top of
each other using the existing generic CPU (rv64) which is also the default
CPU for some time. Implementing a new profile would then be a matter of
adding a new flag instead of a new CPU model.


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

I agree that it's kind of lame to play favorites here and assume that Linux
is the only case that we care about. There's a high chance that other OSes
like FreeBSD might require even less extensions than Linux, so why can't
we use FreeBSD minimal extension set then?

The idea here is less about 'make rv64 a minimal CPU' and more about 'the
generic CPUs should have a predictable extension set'. Having a criteria
like 'It needs to boot Linux' grant that we will not break (too many)
existing users of these generics default CPUs that became used to a random
set of extensions and, all of a sudden, their setup stop working.

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

That's a fair point.

What if we:

- leave the rv64 CPU as is. We'll document the default enabled extensions the
CPU already has and leave it at that. We'll have to refrain from enabling
more default extensions in it though;

- if required, add a new 'barebones' CPU. Call it 'rv64min' or any other
suggestive name. Since it's a new CPU we can really strip it out without
worrying about breaking existing setups. Can be a good CPU for debugging;

- all future profiles are implemented as flags, similar to what we already
do with regular extensions. That will enable us to do things like '-cpu
rv64,rva22U64=true,rva23S64=true' and let user combo profiles that might
be compatible with each other.

And, reproducing here a question LIU Zhiwei asked me in the QEMU SIG meeting,
I believe enabling a profile should do just that - enable a certain set of
extensions. If the user wants to enable a profile and then disable some
mandatory extensions, have at it.


Let me know your thoughts. I have one more prep series to send before
starting the profile implementation, so we have time.


Thanks,

Daniel




>