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

[Andrea Bolognani]

On Thu, Jul 27, 2023 at 08:04:07PM -0300, Daniel Henrique Barboza wrote:
> 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

Good, because as you can see I'm clearly taking my sweet time in
between replies :/ Once again, sorry about that.

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

Is there a concrete use case for layering profiles like that, though?

I've given a quick look to the specification for RVA(20|22|23)U64 and
it looks like subsequent version of each profile are completely
additive: extensions that were optional are now mandatory, new
extensions are introduced as either mandatory or optional. This is in
line with what I was expecting going in.

So, why would I want to do something like

  -cpu rv64,profile=rva20u64,profile=rva23u64

when the latter is a superset of the former? It seems that it would
achieve exactly the same as

  -cpu rv64,profile=rva23u64

but with extra steps.

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

IMO using "can boot Linux" as the criteria is directly at odds with
having "predictable set of extensions" as the goal.

As Linux changes, so will its requirements in terms of extensions. I
don't think that you can resonably work off the assumption that the
set of extensions needed to boot Linux today will be sufficient to
boot Linux 5-10 years from now.

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

Yeah, I agree that it should be possible for users to go out of their
way and create whatever FrankenCPU they like by picking a profile and
then enabling/disabling arbitrary extensions.

I expect that users for this feature are initially going to be
primarily developers; at some point, libvirt's CPU driver will likely
need to use it to define synthetic CPU models that are migratable
between machines with different hardware revisions or coming from
heterogeneous vendors. But that's probably a few more years down the
line :)

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

My opinion so far remains that profiles should be exposed as named
CPU models.

Regarding the fate of rv64, it would make sense to me to turn it into
the Minimum Viable CPU, to use as base for completely custom CPU
models. However, due to backwards compatibility concerns that would
probably have to happen quite some time after the max CPU model has
been introduced, so freezing it in its current state feels like a
sensible idea.

-- 
Andrea Bolognani / Red Hat / Virtualization