Richard Henderson <[email protected]> writes:

> On 2/4/26 23:13, Alex Bennée wrote:
>> FEAT_E2H0 is a formalisation of the existing behaviour of HCR_EL2.E2H
>> being programmable to switch between EL2 host mode and the
>> "traditional" nVHE EL2 mode. This implies at some point we might want
>> to model CPUs without FEAT_E2H0 which will always have EL2 host mode
>> enabled.
>> There are two values to represent no E2H0 systems of which 0b1110
>> will
>> make HCR_EL2.NV1 RES0 for FEAT_NV systems. For FEAT_NV2 the NV1 bit is
>> always valid.
>> Message-ID: <[email protected]>
>> Signed-off-by: Alex Bennée <[email protected]>
>> ---
>> v2
>>    - new helper and properly handling NV1
>> ---
<snip>
>
>> @@ -3801,10 +3802,13 @@ static void do_hcr_write(CPUARMState *env, uint64_t 
>> value, uint64_t valid_mask)
>>               valid_mask |= HCR_GPF;
>>           }
>>           if (cpu_isar_feature(aa64_nv, cpu)) {
>> -            valid_mask |= HCR_NV | HCR_NV1 | HCR_AT;
>> +            valid_mask |= HCR_NV | HCR_AT;
>> +            if (!cpu_isar_feature(aa64_noe2h0_and_nv1_res0, cpu)) {
>> +                valid_mask |= HCR_NV1;
>> +            }
>>           }
>>           if (cpu_isar_feature(aa64_nv2, cpu)) {
>> -            valid_mask |= HCR_NV2;
>> +            valid_mask |= HCR_NV1 | HCR_NV2;
>
> Why add NV1 here?

My reading was if you had FEAT_NV2 then HCR_NV1 was always valid
whatever E2H0 might say. Unless we can validate we don't get
contradictory ID values elsewhere?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Reply via email to