Hi Manoj,
Hi, Yes, your understanding is correct, according to the reference manual, if HaveEL(EL3) and MPAM3_EL3.TRAPLOWER == 1, then any EL2 access to MPAMIDR_EL1 is trapped to EL3 (AArch64.SystemAccessTrap(EL3, 0x18)).
The upstream TF-A master disables this bit : https://review.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+...
Currently there is a strong dependency between feature enablement in EL3 and RMM accessing the registers. We have some patches in progress for RMM to discover feature enablement status in EL3 and only proceed with register access (like MPAM) when explicitly permitted.
Link to the patches for your reference: https://review.trustedfirmware.org/q/topic:%22sm/revlock%22
Thanks -Sona
Manoj Ekbote wrote:
Hi, I am trying to run TF-RMM and there's an exception while reading the MPAMIDR_EL1 register in rmm_arch_init(). if (is_feat_mpam_present()) { unsigned long mpamidr_el1 = read_mpamidr_el1(); .. } The condition to access MPAMIDR_EL1 is: elsif PSTATE.EL == EL2 then if HaveEL(EL3) && EL3SDDUndefPriority() && MPAM3_EL3.TRAPLOWER == '1' then UNDEFINED; elsif HaveEL(EL3) && MPAM3_EL3.TRAPLOWER == '1' then if EL3SDDUndef() then UNDEFINED; else AArch64.SystemAccessTrap(EL3, 0x18); else X[t, 64] = MPAMIDR_EL1; I am running TF-A before TF-RMM, so the default value of 1 in MPAM3_EL3.TRAPLOWER forces all accesses to MPAMIDR_EL1 to be trapped to EL3. And the read in TF-RMM then causes an exception. But there's no handler for the trap in TF-RMM that can forward the read to EL3. Is my understanding right that the code to handle the trap is missing in RMM? Thanks, Manoj
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.