Mohamed Mediouni <[email protected]> writes: >> On 5. Feb 2026, at 13:23, Alex Bennée <[email protected]> wrote: >> >> 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? > KVM with nested virt enabled out of the box exposes a virtual machine with > VHE-only L1 and above, with no allowance for an nVHE nested guest past L1. > > In the Linux kernel in arch/arm64/kvm/nested.c: > > case SYS_ID_AA64MMFR4_EL1: > /* > * You get EITHER > * > * - FEAT_VHE without FEAT_E2H0 > * - FEAT_NV limited to FEAT_NV2 > * - HCR_EL2.NV1 being RES0 > * > * OR > * > * - FEAT_E2H0 without FEAT_VHE nor FEAT_NV > * > * Life is too short for anything else. > */
This is a choice a host can make to simplify things but we want to make sure we could represent hardware that makes a different choice. > > And after taking a further look at the machine readable spec*, 0b1110 is > valid together > with FEAT_NV2, as nothing there says otherwise. > > * > https://developer.arm.com/Architectures/A-Profile%20Architecture#Downloads Is this from the XML or the registers description? >> >> >> -- >> Alex Bennée >> Virtualisation Tech Lead @ Linaro -- Alex Bennée Virtualisation Tech Lead @ Linaro
