Re: [PATCH 2/2] riscv: zicond: make default

[Daniel Henrique Barboza <dbarboza@ventanamicro.com>]

On 8/10/23 15:07, Alistair Francis wrote:
> On Tue, Aug 8, 2023 at 6:10 PM Vineet Gupta <vineetg@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 <vineetg@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-c72d77d5f43b@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
>>