[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support
From: |
Palmer Dabbelt |
Subject: |
Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support |
Date: |
Mon, 10 Jul 2023 11:13:11 -0700 (PDT) |
On Mon, 10 Jul 2023 10:53:12 PDT (-0700), dbarboza@ventanamicro.com wrote:
Hi,
We don't have a 'max' cpu type in riscv32 and riscv64. This is a special,
fictional CPU type that has all possible extensions enabled. It can be
either an alias for a real CPU or a new CPU type. It's used by tooling
such as libvirt for capabilities probing.
Well, in our case it can't be an alias because we don't have any CPU type
that enables all extensions. Which brings me to my first question:
what's the criteria for marking a certain extension default true/false
in rv32/rv64/rv128?
Pretty sure it's just been a somewhat arbitrary decision, with stuff
that's likely to be used being enabled when it's added.
E.g. this is the riscv,isa DT for rv64:
rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu
It has a lot of extensions but it's missing some common ones like svinval
and smstateen.
We can add/remove some extensions from these generic CPUs, document it
and be done with it. I want to propose a different design though:
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;
IMO it's the right idea in spirit, but there's a handful of conflicting
extensions -- mostly vendor stuff, but even some of the standard ones
have conflicting encodings. So I think there's likely to be some
decisions to make there, but when there's conflicts there's usually also
one called out as being aimed at microcontroller-class systems so there
should be a natural choice.
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;
Would we also make incompatible extensions forbidden in the profile
CPUs?
If we add the 23 profiles, we should probably also add some other bases.
We've got a defacto base in Linux that's rv{32,64}ima (plus some cruft
as things have drifted around), I think there's also some interest in
the 22 profiles.
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".
Have a "minimum CPU required to boot Linux" option seems reasonable.
Most users will probably want at least FD and C, though, so maybe we
want something like that as well?
The end result is that we would have a max extensions CPU, a barebones
generic CPU that can be fully customizable from the ground up, and
a profile option to allow users to boost the generic CPUs with a
set of extensions. We will avoid having to deal with generic CPUs having
an (apparently) arbitrary set of extensions.
IMO we still want to keep the ability to turn on/off extensions, the
profiles are a long way from being concrete and we'll still have a lot
of systems floating around that don't line up with them. Being able to
test those configurations in QEMU is a huge benefit for users, even if
it's a headache to keep around all the options.
I don't think we'll have too much opposition on adding (1) so I'll get
on it. I really would like to hear about (2) and (3). (3) will break
users that are using rv64 while counting with that whole set of extensions
that are being enabled by default, but this is why we're going to add
(2) first.
Please comment. Andrea, feel free to give us libvirt/tooling insights.
Thanks,
Daniel
Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support, Andrew Jones, 2023/07/11
Re: RFC: QEMU rv64/rv32 CPU, 'max' CPU and profile support, Andrea Bolognani, 2023/07/27