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