We'll add a new bare CPU type that won't have any default priv_ver. This
means that the CPU will default to priv_ver = 0, i.e. 1.10.0.

At the same we'll allow these CPUs to enable extensions at will, but
then, if the extension has a priv_ver newer than 1.10, we'll end up
disabling it. Users will then need to manually set priv_ver to something
other than 1.10 to enable the extensions they want, which is not ideal.

Change the setter() of extensions to allow user enabled extensions to
bump the priv_ver of the CPU. This will make it convenient for users to
enable extensions for CPUs that doesn't set a default priv_ver.

This change does not affect any existing CPU: vendor CPUs does not allow
extensions to be enabled, and generic CPUs are already set to priv_ver
LATEST.

Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
---
 target/riscv/tcg/tcg-cpu.c | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
index 7670120673..d279314624 100644
--- a/target/riscv/tcg/tcg-cpu.c
+++ b/target/riscv/tcg/tcg-cpu.c
@@ -114,6 +114,26 @@ static int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
     g_assert_not_reached();
 }
 
+static void cpu_validate_multi_ext_priv_ver(CPURISCVState *env,
+                                            uint32_t ext_offset)
+{
+    int ext_priv_ver;
+
+    if (env->priv_ver == PRIV_VERSION_LATEST) {
+        return;
+    }
+
+    ext_priv_ver = cpu_cfg_ext_get_min_version(ext_offset);
+
+    if (env->priv_ver < ext_priv_ver) {
+        /*
+         * Note: the 'priv_spec' command line option, if present,
+         * will take precedence over this priv_ver bump.
+         */
+        env->priv_ver = ext_priv_ver;
+    }
+}
+
 static void cpu_cfg_ext_auto_update(RISCVCPU *cpu, uint32_t ext_offset,
                                     bool value)
 {
@@ -757,6 +777,14 @@ static void cpu_set_misa_ext_cfg(Object *obj, Visitor *v, const char *name,
             return;
         }
 
+        if (misa_bit == RVH && env->priv_ver < PRIV_VERSION_1_12_0) {
+            /*
+             * Note: the 'priv_spec' command line option, if present,
+             * will take precedence over this priv_ver bump.
+             */
+            env->priv_ver = PRIV_VERSION_1_12_0;
+        }
+
         env->misa_ext |= misa_bit;
         env->misa_ext_mask |= misa_bit;
     } else {
@@ -886,6 +914,10 @@ static void cpu_set_multi_ext_cfg(Object *obj, Visitor *v, const char *name,
         return;
     }
 
+    if (value) {
+        cpu_validate_multi_ext_priv_ver(&cpu->env, multi_ext_cfg->offset);
+    }
+
     isa_ext_update_enabled(cpu, multi_ext_cfg->offset, value);
 }
 
-- 
2.41.0

On Thu, Nov 23, 2023 at 03:51:07PM -0300, Daniel Henrique Barboza wrote:
> We'll add a new bare CPU type that won't have any default priv_ver. This
> means that the CPU will default to priv_ver = 0, i.e. 1.10.0.
> 
> At the same we'll allow these CPUs to enable extensions at will, but
> then, if the extension has a priv_ver newer than 1.10, we'll end up
> disabling it. Users will then need to manually set priv_ver to something
> other than 1.10 to enable the extensions they want, which is not ideal.
> 
> Change the setter() of extensions to allow user enabled extensions to
> bump the priv_ver of the CPU. This will make it convenient for users to
> enable extensions for CPUs that doesn't set a default priv_ver.
> 
> This change does not affect any existing CPU: vendor CPUs does not allow
> extensions to be enabled, and generic CPUs are already set to priv_ver
> LATEST.
> 
> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
> ---
>  target/riscv/tcg/tcg-cpu.c | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
> 
> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
> index 7670120673..d279314624 100644
> --- a/target/riscv/tcg/tcg-cpu.c
> +++ b/target/riscv/tcg/tcg-cpu.c
> @@ -114,6 +114,26 @@ static int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
>      g_assert_not_reached();
>  }
>  
> +static void cpu_validate_multi_ext_priv_ver(CPURISCVState *env,
> +                                            uint32_t ext_offset)

We should probably name this cpu_bump_multi_ext_priv_ver(). "validate"
implies we're checking something and either returning an error when it's
not what we expect or asserting on unexpected input. We do neither here,
we just bump priv_ver, when necessary.

Thanks,
drew

On 11/24/23 06:23, Andrew Jones wrote:
> On Thu, Nov 23, 2023 at 03:51:07PM -0300, Daniel Henrique Barboza wrote:
>> We'll add a new bare CPU type that won't have any default priv_ver. This
>> means that the CPU will default to priv_ver = 0, i.e. 1.10.0.
>>
>> At the same we'll allow these CPUs to enable extensions at will, but
>> then, if the extension has a priv_ver newer than 1.10, we'll end up
>> disabling it. Users will then need to manually set priv_ver to something
>> other than 1.10 to enable the extensions they want, which is not ideal.
>>
>> Change the setter() of extensions to allow user enabled extensions to
>> bump the priv_ver of the CPU. This will make it convenient for users to
>> enable extensions for CPUs that doesn't set a default priv_ver.
>>
>> This change does not affect any existing CPU: vendor CPUs does not allow
>> extensions to be enabled, and generic CPUs are already set to priv_ver
>> LATEST.
>>
>> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
>> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
>> ---
>>   target/riscv/tcg/tcg-cpu.c | 32 ++++++++++++++++++++++++++++++++
>>   1 file changed, 32 insertions(+)
>>
>> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
>> index 7670120673..d279314624 100644
>> --- a/target/riscv/tcg/tcg-cpu.c
>> +++ b/target/riscv/tcg/tcg-cpu.c
>> @@ -114,6 +114,26 @@ static int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
>>       g_assert_not_reached();
>>   }
>>   
>> +static void cpu_validate_multi_ext_priv_ver(CPURISCVState *env,
>> +                                            uint32_t ext_offset)
> 
> We should probably name this cpu_bump_multi_ext_priv_ver(). "validate"
> implies we're checking something and either returning an error when it's
> not what we expect or asserting on unexpected input. We do neither here,
> we just bump priv_ver, when necessary.

Having a look at all the instances we have of 'validate', including the rva22s64 series,
I believe we can make the following name changes:

riscv_cpu_validate_named_features() -> riscv_cpu_update_named_features()
riscv_cpu_validate_svade() -> riscv_cpu_update_svade()
riscv_cpu_validate_zic64b() -> riscv_cpu_update_zic64b()

As you said a couple of times in recente reviews, 'validate' doesn't make much sense
since we're not checking values and erroring out/send warnings about it. I suggest
'update' instead of 'set' because we're updating the value of these flags based on
the resulting configuration during finalize(), instead of setting them to a certain
'value' param.


Thanks,

Daniel


> 
> Thanks,
> drew

On 11/24/23 08:55, Daniel Henrique Barboza wrote:
> 
> 
> On 11/24/23 06:23, Andrew Jones wrote:
>> On Thu, Nov 23, 2023 at 03:51:07PM -0300, Daniel Henrique Barboza wrote:
>>> We'll add a new bare CPU type that won't have any default priv_ver. This
>>> means that the CPU will default to priv_ver = 0, i.e. 1.10.0.
>>>
>>> At the same we'll allow these CPUs to enable extensions at will, but
>>> then, if the extension has a priv_ver newer than 1.10, we'll end up
>>> disabling it. Users will then need to manually set priv_ver to something
>>> other than 1.10 to enable the extensions they want, which is not ideal.
>>>
>>> Change the setter() of extensions to allow user enabled extensions to
>>> bump the priv_ver of the CPU. This will make it convenient for users to
>>> enable extensions for CPUs that doesn't set a default priv_ver.
>>>
>>> This change does not affect any existing CPU: vendor CPUs does not allow
>>> extensions to be enabled, and generic CPUs are already set to priv_ver
>>> LATEST.
>>>
>>> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
>>> Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
>>> ---
>>>   target/riscv/tcg/tcg-cpu.c | 32 ++++++++++++++++++++++++++++++++
>>>   1 file changed, 32 insertions(+)
>>>
>>> diff --git a/target/riscv/tcg/tcg-cpu.c b/target/riscv/tcg/tcg-cpu.c
>>> index 7670120673..d279314624 100644
>>> --- a/target/riscv/tcg/tcg-cpu.c
>>> +++ b/target/riscv/tcg/tcg-cpu.c
>>> @@ -114,6 +114,26 @@ static int cpu_cfg_ext_get_min_version(uint32_t ext_offset)
>>>       g_assert_not_reached();
>>>   }
>>> +static void cpu_validate_multi_ext_priv_ver(CPURISCVState *env,
>>> +                                            uint32_t ext_offset)
>>
>> We should probably name this cpu_bump_multi_ext_priv_ver(). "validate"
>> implies we're checking something and either returning an error when it's
>> not what we expect or asserting on unexpected input. We do neither here,
>> we just bump priv_ver, when necessary.
> 
> Having a look at all the instances we have of 'validate', including the rva22s64 series,
> I believe we can make the following name changes:> 
> riscv_cpu_validate_named_features() -> riscv_cpu_update_named_features()
> riscv_cpu_validate_svade() -> riscv_cpu_update_svade()
> riscv_cpu_validate_zic64b() -> riscv_cpu_update_zic64b()


Thinking a littme more about it, and I think you hinted at this in the review of rva22s64,
we could get rid of all these functions that are doing simple assignments and open-code
everything in riscv_cpu_update_named_features().

I'll do that for v12. Thanks,

Daniel

> 
> As you said a couple of times in recente reviews, 'validate' doesn't make much sense
> since we're not checking values and erroring out/send warnings about it. I suggest
> 'update' instead of 'set' because we're updating the value of these flags based on
> the resulting configuration during finalize(), instead of setting them to a certain
> 'value' param.
> 
> 
> Thanks,
> 
> Daniel
> 
> 
>>
>> Thanks,
>> drew