[PATCH] arm64: Revamp HCR_EL2.E2H RES1 detection

[Jan Kotas]

> On 9 Oct 2025, at 16:10, Marc Zyngier <maz at kernel.org> wrote:
> 
> EXTERNAL MAIL
> 
> 
> On Thu, 09 Oct 2025 14:00:22 +0100,
> Mark Rutland <mark.rutland at arm.com> wrote:
>> 
>> On Thu, Oct 09, 2025 at 01:12:39PM +0100, Marc Zyngier wrote:
>>> We currently have two ways to identify CPUs that only implement FEAT_VHE
>>> and not FEAT_E2H0:
>>> 
>>> - either they advertise it via ID_AA64MMFR4_EL1.E2H0,
>>> - or the HCR_EL2.E2H bit is RAO/WI
>>> 
>>> However, there is a third category of "cpus" that fall between these
>>> two cases: on CPUs that do not implement FEAT_FGT, it is IMPDEF whether
>>> an access to ID_AA64MMFR4_EL1 can trap to EL2 when the register value
>>> is zero.
>>> 
>>> A consequence of this is that on systems such as Neoverse V2, a NV
>>> guest cannot reliably detect that it is in a VHE-only configuration
>>> (E2H is writable, and ID_AA64MMFR0_EL1 is 0), despite the hypervisor's
>>> best effort to repaint the id register.
>>> 
>>> Replace the RAO/WI test by a sequence that makes use of the VHE
>>> register remnapping between EL1 and EL2 to detect this situation,
>>> and work out whether we get the VHE behaviour even after having
>>> set HCR_EL2.E2H to 0.
>>> 
>>> This solves the NV problem, and provides a more reliable acid test
>>> for CPUs that do not completely follow the letter of the architecture
>>> while providing a RES1 behaviour for HCR_EL2.E2H.
>>> 
>>> Suggested-by: Marc Rutland <mark.rutland at arm.com>
>>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>>> Link: https://urldefense.com/v3/__https://lore.kernel.org/r/15A85F2B-1A0C-4FA7-9FE4-EEC2203CC09E@global.cadence.com__;!!EHscmS1ygiU1lA!CgHR7mq8v0OMxlFNUnMJU9oQbdQUMKM4aqCTSj6AfXwJUJssNBDP_LJCfmcZuKxkC-aq1Ce7$
>>> ---
>>> arch/arm64/include/asm/el2_setup.h | 30 ++++++++++++++++++++++++------
>>> 1 file changed, 24 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h
>>> index 46033027510cc..b7640e2c20503 100644
>>> --- a/arch/arm64/include/asm/el2_setup.h
>>> +++ b/arch/arm64/include/asm/el2_setup.h
>>> @@ -24,22 +24,40 @@
>>>  * ID_AA64MMFR4_EL1.E2H0 < 0. On such CPUs HCR_EL2.E2H is RES1, but it
>>>  * can reset into an UNKNOWN state and might not read as 1 until it has
>>>  * been initialized explicitly.
>>> -  *
>>> -  * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
>>> -  * don't advertise it (they predate this relaxation).
>>> -  *
>>>  * Initalize HCR_EL2.E2H so that later code can rely upon HCR_EL2.E2H
>>>  * indicating whether the CPU is running in E2H mode.
>>>  */
>>> mrs_s x1, SYS_ID_AA64MMFR4_EL1
>>> sbfx x1, x1, #ID_AA64MMFR4_EL1_E2H0_SHIFT, #ID_AA64MMFR4_EL1_E2H0_WIDTH
>>> cmp x1, #0
>>> - b.ge .LnVHE_\@
>>> + b.lt .LnE2H0_\@
>>> 
>> 
>>> + /*
>>> +  * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but don't
>>> +  * advertise it (they predate this relaxation). Check for an
>>> +  * essential VHE property (system register remapping) to decide
>>> +  * whether we're effectively VHE-only or not.
>>> +  *
>>> +  * This is also useful for for NV guests on CPUs that can't trap
>>> +  * ID_AA64MMFR4_EL1 as they don't have FEAT_FGT.
>>> +  */
>> 
>> Would you be happy to elaborate this comment to:
>> 
>> /*
>>  * Unfortunately, HCR_EL2.E2H can be RES1 even if not advertised
>>  * as such via ID_AA64MMFR4_EL1.E2H0:
>>  *
>>  * - Fruity CPUs predate the !FEAT_E2H0 relaxation, and seem to
>>  *   have HCR_EL2.E2H implemented as RAO/WI.
>>  *
>>  * - On CPUs that lack FEAT_FGT, a hypervisor can't trap guest
>>  *   reads of ID_AA64MMFR4_EL1 to advertise !FEAT_E2H0. NV
>>  *   guests on these hosts can write to HCR_EL2.E2H without
>>  *   trapping to the hypervisor, but these writes have no
>>  *   functional effect.
>>  *
>>  * Handle both cases by checking for an essential VHE property
>>  * (system register remapping) to decide whether we're
>>  * effectively VHE-only or not.
>>  */
> 
> Yup. Applied.
> 
>> 
>> Other than that, this all looks good to me:
>> 
>> Acked-by: Mark Rutland <mark.rutland at arm.com>

I tested on a Neoverse-V2 machine.
Works as expected with KVM_ARM_VCPU_HAS_EL2_E2H0, and without it. 

Tested-by: Jan Kotas <jank at cadence.com>

Regards,
Jan

> 
> Thanks!
> 
> M.
> 
> -- 
> Without deviation from the norm, progress is not possible.