Advertise FEAT_MEC in AA64MMFR3 ID register for the Arm64 cpu max as a
first step to fully support FEAT_MEC.

The FEAT_MEC is an extension to FEAT_RME that implements multiple
Memory Encryption Contexts (MEC) so the memory in a realm can be
encrypted and accessing it from the wrong encryption context is not
possible. An encryption context allow the selection of a memory
encryption engine.

At this point, no real memory encryption or obfuscation is supported,
but software stacks that rely on FEAT_MEC to run should work properly,
except if they use the new cache management instructions, which will
be implement in a subsequent commit.

Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org>
---
 docs/system/arm/emulation.rst | 1 +
 target/arm/cpu-features.h     | 5 +++++
 target/arm/tcg/cpu64.c        | 1 +
 3 files changed, 7 insertions(+)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 611d7385d8..14f17febe2 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -89,6 +89,7 @@ the following architecture extensions:
 - FEAT_LSE (Large System Extensions)
 - FEAT_LSE2 (Large System Extensions v2)
 - FEAT_LVA (Large Virtual Address space)
+- FEAT_MEC (Memory Encryption Contexts)
 - FEAT_MixedEnd (Mixed-endian support)
 - FEAT_MixedEndEL0 (Mixed-endian support at EL0)
 - FEAT_MOPS (Standardization of memory operations)
diff --git a/target/arm/cpu-features.h b/target/arm/cpu-features.h
index e6a731472f..009618fd9c 100644
--- a/target/arm/cpu-features.h
+++ b/target/arm/cpu-features.h
@@ -603,6 +603,11 @@ static inline bool isar_feature_aa64_hbc(const ARMISARegisters *id)
     return FIELD_EX64(id->id_aa64isar2, ID_AA64ISAR2, BC) != 0;
 }
 
+static inline bool isar_feature_aa64_mec(const ARMISARegisters *id)
+{
+    return FIELD_EX64(id->id_aa64mmfr3, ID_AA64MMFR3, MEC);
+}
+
 static inline bool isar_feature_aa64_mops(const ARMISARegisters *id)
 {
     return FIELD_EX64(id->id_aa64isar2, ID_AA64ISAR2, MOPS);
diff --git a/target/arm/tcg/cpu64.c b/target/arm/tcg/cpu64.c
index 5f77d320ea..1a127f6cf7 100644
--- a/target/arm/tcg/cpu64.c
+++ b/target/arm/tcg/cpu64.c
@@ -1243,6 +1243,7 @@ void aarch64_max_tcg_initfn(Object *obj)
     t = cpu->isar.id_aa64mmfr3;
     t = FIELD_DP64(t, ID_AA64MMFR3, SPEC_FPACC, 1); /* FEAT_FPACC_SPEC */
     t = FIELD_DP64(t, ID_AA64MMFR3, SCTLRX, 1);     /* FEAT_SCTLR2 */
+    t = FIELD_DP64(t, ID_AA64MMFR3, MEC, 1);        /* FEAT_MEC */
     cpu->isar.id_aa64mmfr3 = t;
 
     t = cpu->isar.id_aa64zfr0;
-- 
2.34.1

On 7/4/25 09:14, Gustavo Romero wrote:
> Advertise FEAT_MEC in AA64MMFR3 ID register for the Arm64 cpu max as a
> first step to fully support FEAT_MEC.
> 
> The FEAT_MEC is an extension to FEAT_RME that implements multiple
> Memory Encryption Contexts (MEC) so the memory in a realm can be
> encrypted and accessing it from the wrong encryption context is not
> possible. An encryption context allow the selection of a memory
> encryption engine.
> 
> At this point, no real memory encryption or obfuscation is supported,
> but software stacks that rely on FEAT_MEC to run should work properly,
> except if they use the new cache management instructions, which will
> be implement in a subsequent commit.

You really need to implement the new cache instruction before exposing this feature.  Like 
other cache instructions, the insn can be a nop.  All you need is the accessfn to trap 
when EL2 and !SS_Realm.

> diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
> index 611d7385d8..14f17febe2 100644
> --- a/docs/system/arm/emulation.rst
> +++ b/docs/system/arm/emulation.rst
> @@ -89,6 +89,7 @@ the following architecture extensions:
>   - FEAT_LSE (Large System Extensions)
>   - FEAT_LSE2 (Large System Extensions v2)
>   - FEAT_LVA (Large Virtual Address space)
> +- FEAT_MEC (Memory Encryption Contexts)

We probably want to document that this is a stub implementation.

>   - FEAT_MixedEnd (Mixed-endian support)
>   - FEAT_MixedEndEL0 (Mixed-endian support at EL0)
>   - FEAT_MOPS (Standardization of memory operations)
> diff --git a/target/arm/cpu-features.h b/target/arm/cpu-features.h
> index e6a731472f..009618fd9c 100644
> --- a/target/arm/cpu-features.h
> +++ b/target/arm/cpu-features.h
> @@ -603,6 +603,11 @@ static inline bool isar_feature_aa64_hbc(const ARMISARegisters *id)
>       return FIELD_EX64(id->id_aa64isar2, ID_AA64ISAR2, BC) != 0;
>   }
>   
> +static inline bool isar_feature_aa64_mec(const ARMISARegisters *id)
> +{
> +    return FIELD_EX64(id->id_aa64mmfr3, ID_AA64MMFR3, MEC);
> +}

This test (updated for master of course) needs to be in the first patch, because you're 
using it in the implementations of SCTLR2 and TCR2.  So patches 2 and 3 don't build alone 
at the moment.

Alternately, implement SCTLR2 + TCR2 without *any* other features which would enable valid 
write bits, and then add the MEC code here.


r~

Hi Richard,

Thanks a lot for the reviews!

On 7/4/25 19:56, Richard Henderson wrote:
> On 7/4/25 09:14, Gustavo Romero wrote:
>> Advertise FEAT_MEC in AA64MMFR3 ID register for the Arm64 cpu max as a
>> first step to fully support FEAT_MEC.
>>
>> The FEAT_MEC is an extension to FEAT_RME that implements multiple
>> Memory Encryption Contexts (MEC) so the memory in a realm can be
>> encrypted and accessing it from the wrong encryption context is not
>> possible. An encryption context allow the selection of a memory
>> encryption engine.
>>
>> At this point, no real memory encryption or obfuscation is supported,
>> but software stacks that rely on FEAT_MEC to run should work properly,
>> except if they use the new cache management instructions, which will
>> be implement in a subsequent commit.
> 
> You really need to implement the new cache instruction before exposing this feature.  Like other cache instructions, the insn can be a nop.  All you need is the accessfn to trap when EL2 and !SS_Realm.

Got it. Thanks, I'm looking at it right now. I'm sending v3 addressing your
comments here and then in v4 I'll introduce the cache management insns.


>> diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
>> index 611d7385d8..14f17febe2 100644
>> --- a/docs/system/arm/emulation.rst
>> +++ b/docs/system/arm/emulation.rst
>> @@ -89,6 +89,7 @@ the following architecture extensions:
>>   - FEAT_LSE (Large System Extensions)
>>   - FEAT_LSE2 (Large System Extensions v2)
>>   - FEAT_LVA (Large Virtual Address space)
>> +- FEAT_MEC (Memory Encryption Contexts)
> 
> We probably want to document that this is a stub implementation.

Where exactly? Maybe just below:

When a specific named CPU is being emulated, only those features which
are present in hardware for that CPU are emulated. (If a feature is
not in the list above then it is not supported, even if the real
hardware should have it.) The ``max`` CPU enables all features.

or ?

Can I use the term "stub implementation" in the docs?


>>   - FEAT_MixedEnd (Mixed-endian support)
>>   - FEAT_MixedEndEL0 (Mixed-endian support at EL0)
>>   - FEAT_MOPS (Standardization of memory operations)
>> diff --git a/target/arm/cpu-features.h b/target/arm/cpu-features.h
>> index e6a731472f..009618fd9c 100644
>> --- a/target/arm/cpu-features.h
>> +++ b/target/arm/cpu-features.h
>> @@ -603,6 +603,11 @@ static inline bool isar_feature_aa64_hbc(const ARMISARegisters *id)
>>       return FIELD_EX64(id->id_aa64isar2, ID_AA64ISAR2, BC) != 0;
>>   }
>> +static inline bool isar_feature_aa64_mec(const ARMISARegisters *id)
>> +{
>> +    return FIELD_EX64(id->id_aa64mmfr3, ID_AA64MMFR3, MEC);
>> +}
> 
> This test (updated for master of course) needs to be in the first patch, because you're using it in the implementations of SCTLR2 and TCR2.  So patches 2 and 3 don't build alone at the moment.

I've moved it to the first FEAT_MEC patch, thanks.


Cheers,
Gustavo

> Alternately, implement SCTLR2 + TCR2 without *any* other features which would enable valid write bits, and then add the MEC code here.
> 
> 
> r~