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

[Andrea Bolognani]

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
that users have to assemble themselves by layering profiles?

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.

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

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.

-- 
Andrea Bolognani / Red Hat / Virtualization