On 8/10/23 15:07, Alistair Francis wrote:
On Tue, Aug 8, 2023 at 6:10 PM Vineet Gupta <vine...@rivosinc.com> wrote:
On 8/8/23 14:06, Daniel Henrique Barboza wrote:
(CCing Alistair and other reviewers)
On 8/8/23 15:17, Vineet Gupta wrote:
Again this helps with better testing and something qemu has been doing
with newer features anyways.
Signed-off-by: Vineet Gupta <vine...@rivosinc.com>
---
Even if we can reach a consensus about removing the experimental (x-
prefix) status
from an extension that is Frozen instead of ratified, enabling stuff
in the default
CPUs because it's easier to test is something we would like to avoid.
The rv64
CPU has a random set of extensions enabled for the most different and
undocumented
reasons, and users don't know what they'll get because we keep beefing
up the
generic CPUs arbitrarily.
The idea was to enable "most" extensions for the virt machine. It's a
bit wishy-washy, but the idea was to enable as much as possible by
default on the virt machine, as long as it doesn't conflict. The goal
being to allow users to get the "best" experience as all their
favourite extensions are enabled.
It's harder to do in practice, so we are in a weird state where users
don't know what is and isn't enabled.
We probably want to revisit this. We should try to enable what is
useful for users and make it clear what is and isn't enabled. I'm not
clear on how best to do that though.
Yeah, thing is how we define 'useful for users'. If you take a look at this
thread where we discussed the 'max' CPU design:
https://lore.kernel.org/qemu-riscv/35a847a1-2720-14ab-61b0-c72d77d5f...@ventanamicro.com/
The 'max' CPU design is rather straightforward, the profile support is also
straightforward (I'll work on that soon), but the role of the rv64 CPU is
confusing.
IMO we should freeze the current rv64 extensions, document it, and the leave
it alone unless we have a very good reason to enable more stuff. We'll have the
max CPU for the use case where users want the maximum amount of stable features
and, with profile support, we can make rv64 operate with a predictable set of
extensions. Seems like a good coverage.
Thanks,
Daniel
Again, I think this comes back to we need to version the virt machine.
I might do that as a starting point, that allows us to make changes in
a clear way.
I understand this position given the arbitrary nature of gazillion
extensions. However pragmatically things like bitmanip and zicond are so
fundamental it would be strange for designs to not have them, in a few
years. Besides these don't compete or conflict with other extensions.
But on face value it is indeed possible for vendors to drop them for
various reasons or no-reasons.
But having the x- dropped is good enough for our needs as there's
already mechanisms to enable the toggles from elf attributes.
Starting on QEMU 8.2 we'll have a 'max' CPU type that will enable all
non-experimental
and non-vendor extensions by default, making it easier for tooling to
test new
features/extensions. All tooling should consider changing their
scripts to use the
'max' CPU when it's available.
That would be great.
The max CPU helps, but I do feel that the default should allow users
to experience as many RISC-V extensions/features as practical.
Alistair
For now, I fear that gcc and friends will still need to enable
'zicond' in the command
line via 'zicond=true'. Thanks,
Thx,
-Vineet
