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~
