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

[Andrea Bolognani]

On Mon, Sep 11, 2023 at 07:01:38PM -0300, Daniel Henrique Barboza wrote:
> On 9/11/23 16:46, Daniel Henrique Barboza wrote:
> > On 9/8/23 11:10, Andrew Jones wrote:
> > > On Fri, Sep 08, 2023 at 03:28:12AM -0700, Andrea Bolognani wrote:
> > > > Wouldn't that be exposed as a named vendor CPU rather than something
> > > > 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).

Right, that's what I had in mind when I was talking about layering.
Using the term union is probably more appropriate though :)

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

I'm not sure this will save a lot of typing unless you're enabling a
lot of profiles which are possibly far apart from each other in terms
of release year, but I also don't have a very strong opposition to
the approach. As you say, we are already effectively implementing it
with virtual extensions like "g", so extending the applicability
further to cover profiles is not too much of a stretch.

I think libvirt will probably need to learn what set of extensions
each virtual extension/profile maps to, but since the definition will
come directly from actual specifications that shouldn't be a big
problem.

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

Fair enough.

Should there be a way to explicitly enable all possible optional
extensions, then? To allow the developer to verify that the
application works correctly on a minimal implementation of the
profile, but also takes advantage of optional extensions if they are
present? Or would that be achieved by enabling the relevant
extensions manually? Or perhaps by using the max CPU model instead?

> > > 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).
> >
> > This makes sense when/if we unify the 32 and 64 bit binaries (CCing 
> > Alistair for
> > context). Today we have 32 and 64 bit CPUs in their own binaries (riscv32 
> > and
> > riscv64) and it's not possible to run a 32 bit CPU with qemu-system-riscv64 
> > because
> > we do not expose xlen or mxl to be set via command line.
> >
> >
> > As for the 'max' CPU I'm having second guesses about its name. We have 
> > 'rv32' and
> > 'rv64', but 'max' can be either 32 or 64 bit depending on the binary used. 
> > This can
> > be considered an advantage now but it can be confusing if/when we decide to 
> > merge
> > all CPUs in a single binary. I believe a better name would be 
> > rv32max/rv64max or
> > max32/max64. Any thoughts?
>
> Guess I'll answer my own question. Another thing with the 'max' CPU name is 
> that all
> other archs uses the same CPU name for a similar concept. Use the same name 
> will spare
> libvirt and other tooling from having to deal with every other arch having a 
> 'max' CPU
> and risc-v using another name.
>
> We might eventually have to deal with an unified binary with both 32 and 64 
> bits CPUs
> and then 'max' will need to be disambiguated via max32/max64 aliases or xlen 
> properties.
> For now we should keep 'max' as is.

Agreed.

As you note, when the time comes this is something that all
architectures, not just RISC-V, will have to deal with.

-- 
Andrea Bolognani / Red Hat / Virtualization