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

[Andrew Jones]

On Fri, Sep 08, 2023 at 03:28:12AM -0700, Andrea Bolognani wrote:
> On Fri, Sep 08, 2023 at 11:13:54AM +0200, Andrew Jones wrote:
> > On Fri, Sep 08, 2023 at 10:39:45AM +0200, Andrew Jones wrote:
> > > On Thu, Sep 07, 2023 at 10:51:33AM -0500, Andrea Bolognani wrote:
> > > > 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.
> > >
> > > I don't see anything in the profile spec that states we can count on later
> > > profiles being supersets of older profiles, which means we cannot.
> >
> > I just found a potential example of why we cannot. A recent mail thread[1]
> > stated some vendors are considering dropping support for the C extension
> > on "higher end" platforms. If this were to happen, then a profile may be
> > proposed where C is optional. In that case, platforms that still have C
> > could state they are compatible with the older profiles where it's
> > mandated and also the new profile where it's optional, whereas the
> > platforms that don't have C will only state the new profile.
> >
> > [1] https://groups.google.com/a/riscv.org/g/fw-exchange/c/qxnKKS4jhLk
> 
> I can't access the URL, but I get the gist. Point taken about
> profiles not necessarily being purely additive, though I don't think
> this invalidates my criticism of the approach.
> 
> > > Also,
> > > I'd guess vendors will want to implement as broad a set as possible of
> > > profiles and then list them all when advertising. So, IMO, something like
> > > '-cpu rv64,rva20u64=on,rva23u64=on' would be a more natural way to model a
> > > cpu which advertises being compatible with those two profiles.
> 
> Wouldn't that be exposed as a named vendor CPU rather than something

Probably eventually, but I think it'd be nice to translate a CPU
description to a QEMU command line without having to do anything other
than specify a base CPU model and a list of extensions, where most of the
extensions could get enabled through the selection of profiles without
even having to know which ones.

> that users have to assemble themselves by layering profiles?

Combing multiple profiles should be considered as creating a union of the
mandatory extensions each profile represents, rather than as layering.

Let's take the hypothetical case of C being dropped from rva24u64 as an
example. When specifying both rva22u64 and rva24u64
(-cpu min64,rva22u64=on,rva24u64=on) the user will get C enabled without
even having to know about it, whereas if the user could only select the
latest profile (-cpu rva24u64), C would not get enabled unless the user
was aware that it needed to be explicitly enabled (-cpu rva24u64,c=on).

(I changed the name of the base CPU type in the example above to 'min64'.
More on that below.)

> 
> Note that I have zero issues with the implementation of said named
> vendor CPU being, internally, handled effectively the same way as
> what you've just described. I'm simply unconvinced that we should
> expose this mechanism to users.
> 
> > > (I swapped the 'profile=' to a '=on' syntax, because I think each profile
> > > should be a boolean "virtual" extension.)
> 
> On one hand, I like this because it avoids having to invent a new
> mechanism. On the other, I dislike it because it overloads an
> existing mechanism O:-)
> 
> > > I'm also not sure of the benefits of using a cpu model vs. a base model
> > > and a bunch of virtual profile extensions. If it's because it's a hassle
> > > to collect extensions that should be enabled, then I think we'll have to
> > > live with that for unnamed riscv cpu models. Profiles will always lag new
> > > extensions which users will want to enable, so users will be adding plenty
> > > of cpu properties anyway. Of course users that don't care about being
> > > explicit have 'max' to avoid all that.
> 
> I feel that this validates my stance on the matter.
> 
> If you're working on defining a new CPU model and need fine-grained
> control over the exact set of extensions, then you can already do
> that by explicitly flipping each one of them on or off, and adding
> the ability to layer profiles doesn't add much value except possibly
> removing a bit of verbosity. Not particularly compelling IMO.

I think it's compelling, because the extension lists that profiles provide
are long and mostly uninteresting. For example, how often do we want to
type and think about imafd_Zicsr_Zifencei? I think we'd mostly rather take
those for granted, and we can, because we just specify 'g' instead. Indeed
the profile spec even points out that using profiles as a way to deal with
"unwieldy" ISA strings is another motivation for them. A RISC-V QEMU CPU
command line is effectively an ISA string, so I think it's appropriate to
apply profiles to it as well.

> 
> If you're testing an application and want to ensure it works fine on
> CPUs that implement a specific profile, e.g. rva20u64 because even
> older hardware should be able to run it, then you're not going to
> need or indeed want to layer additional profiles on top of that. So a
> regular named CPU model will work just fine.

This line of reasoning makes sense if profiles only layer, but, as I tried
to illustrate above, we should consider profile combining to be the
forming of extension unions, where even the older profiles can contribute
to the set.

> 
>   (This also gets really interesting when you start thinking about
>   extensions that are optional for the profile... Maybe we need
>   something like '-cpu rva23u64,optional-extensions=off' so that
>   testing against the baseline for a profile doesn't require combing
>   through the spec and disabling extensions manually?)

I don't think the profiles (whether they are CPU virtual extensions or
CPU models) should enable the optional extensions by default. When
software targets a profile (or set of profiles with the virtual
extension approach) then it should never assume the optional extensions
will be present. Developers should need to consciously include those
extensions when creating the QEMU platform used for testing.

> 
> If you're someone who just needs a RISC-V VM, then you're either
> going to be using 'max' or a named vendor CPU and profiles will not
> enter the picture at all.

I agree, but I think we need to ensure developers can easily build more
specific platforms too, including those that combine profiles.


Now somewhat switching topics...

Thinking about this more today, I think we should have two non-vendor CPU
models ('min' and 'max'). We also need to handle xlen, though, so I
suggest we have min32, min64, max32 and max64 (and someday min128 and
max128), but those would just be convenience CPU model names. The same
CPU models could be created with 'min,xlen32=on', 'min,xlen64=on',
'max,xlen32=on', and 'max,xlen64=on' instead (and one could replace xlen*
with both an mxlen* and an sxlen* when they don't match).

Besides the *xlen* boolean properties, 'min' and 'max', would both also
get 'version1', 'version2', ... boolean properties which map to the ISA
spec version(s) supported. (min32, min64, max32, and max64 would always
implement the latest version in order to remain useful shorthands.)

In the end users could choose between
 - vendor named models
 - min/max,xlen*,version* + profiles/extensions...
 - min32/max32/min64/max64 + profiles/extensions...
 - host (for KVM, and max/max32/max64 could all alias 'host')

'any', 'rv32', and 'rv64' get deprecated.

Thanks,
drew