I can access ICC_IAR1_EL1 at EL3 using SP_EL0, however, after I switch EL3 to EL1 non-secure, I can't read IIC_IAR1_EL1 anymore, which doesn't make sense.
Can anybody help here? much appreciated.
__func__011000 EC=MSR, MRS, or System instruction, that isn't reported using EC 0x00/0x01/0x07Unhandled exception 0x18(24) from CA72_0 to CA72_0EXC number:0x00000018EXC class: 0x00000018FaultReg: 0x00000000StatusPrg: 0x80000005PC: 0x00000000 0xA0007F78 FaultReg: 0xD538CC00StatusPrg: 0x00303019Exception class is MSR_MRS These report exceptions from MSR, MRS, or System instructions Instruction syndrome MSR/MRS: Op0: 0x00000000Op2: 0x00000000Op1: 0x00000000CRn: 0x00000000Rt : 0x00000000CRm: 0x00000018dir: 0x00000001
The ICC_IAR1_EL1 register description describes when accessing the register can trigger an exception (see near the end):
Arm A-profile Architecture Registers
Looking at the EL1 accessor:
elsif PSTATE.EL == EL1 then if HaveEL(EL3) && EL3SDDUndefPriority() && SCR_EL3.IRQ == '1' then UNDEFINED; elsif ICC_SRE_EL1.SRE == '0' then AArch64.SystemAccessTrap(EL1, 0x18); elsif EL2Enabled() && ICH_HCR_EL2.TALL1 == '1' then AArch64.SystemAccessTrap(EL2, 0x18); elsif EL2Enabled() && HCR_EL2.IMO == '1' then X[t, 64] = ICV_IAR1_EL1; elsif HaveEL(EL3) && SCR_EL3.IRQ == '1' then if EL3SDDUndef() then UNDEFINED; else AArch64.SystemAccessTrap(EL3, 0x18); else X[t, 64] = ICC_IAR1_EL1;
Given the exception is being taken to EL1, that looks like the second trap:
elsif ICC_SRE_EL1.SRE == '0' then AArch64.SystemAccessTrap(EL1, 0x18);
That is, the access traps due to ICC_SRE_EL1.SRE being cleared to 0.
Something that has tripped me a couple of times is that ICC_SRE_EL1 is banked, meaning there are separate copies for Secure and Non-secure state. Which you currently see/use is based on SCR_EL3.NS. If you pre-initialised ICC_SRE_EL1.SRE while in EL3, you might have initialised the "wrong" copy (i.e. not the one for the Security state you entered EL1 in). My suggestion would be to initialise both copies while in EL3.
Hi Martin,
Thanks very much for your always help!! Your answer always help me a lot.
Following you suggestion, I tried to check ICC_SRE_EL1_S and ICC_SRE_EL1_NS at EL3 by changing SCR_EL3.NS.
Seems both of ICC_SRE_EL1_S and ICC_SRE_EL1_NS are set to 0x7 already.
My Test Log is showed below.
icc_sre_el1 is 0x7 // checking ICC_SRE_EL1_SSCR_EL3 is 0xc0e // checking SCR_EL3.NS, which is 0x0 by default after initialization
SCR_EL3 is 0xc0f // setting SCR_EL3.NS to 0x1icc_sre_el1 is 0x7 // checking ICC_SRE_EL1_NS
HCR_EL2 is 0x0 // Got HCR_EL2 0x0, cause I read it at EL3ICC IAR1 EL1 is 0x3ff // checking ICC_IAR1_EL1
enter non-secure worldtransition_to_lower_el :Current EL is EL2transition_to_lower_el :Current EL is EL1
current EL is 0x4
Try to read ICC_IAR1_EL1 again, but got error below:
__func__011000 EC=MSR, MRS, or System instruction, that isn't reported using EC 0x00/0x01/0x07Unhandled exception 0x18(24) from CA72_0 to CA72_0EXC number:0x00000018EXC class: 0x00000018FaultReg: 0x00000000StatusPrg: 0x60000004PC: 0x00000000 0xA0007DCC FaultReg: 0xD538CC00StatusPrg: 0x00303019Exception class is MSR_MRS These report exceptions from MSR, MRS, or System instructions Instruction syndrome MSR/MRS: Op0: 0x00000000Op2: 0x00000000Op1: 0x00000000CRn: 0x00000000Rt : 0x00000000CRm: 0x00000018dir: 0x00000001
Much appreciated for guiding me how to understand the accessor! I eventually figure out what's happening.
My ICC_IAR1_EL1 reading is trapped as below.
After I setting SCR_EL3 from 0xc0f to 0xc0d (setting IRQ from 1 to 0, and setting NS from 0 to 1), I can read out ICC_IAR1_EL1_NS successfully.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
icc_sre_el1 is 0x7icc_sre_el3 is 0x7
SCR_EL3 is 0xc0e
SCR_EL3 is 0xc0dicc_sre_el1 is 0x7ICC IAR1 EL1 is 0x3ffenter non-secure worldtransition_to_lower_el :Current EL is EL2
HCR_EL2 is 0x0transition_to_lower_el :Current EL is EL1
current EL is 0x4ICC IAR1 EL1 is 0x3ff
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
BTW, I am wondering if I go into "UNDEFINED" what's going to happen? system crash? thanks in advance.
Hmm, interesting.
A few questions then:
Not sure why my previous reply at last night was flagged by as inappropriate and doesn't appear on the site. But it's back now.
Could you kindly help to review my previous reply? thanks in advance.
Ok, that makes sense. The trap was to EL3, not EL1.
UNDEFINED means you'll take a synchronous exception with a different ESR_ELx.EC code. The practical difference between a "trap" and UNDEF is that traps are (usually) expected to be recovered from. You trap the access, do something, and then either re-execute the trapped instruction or emulate it. With UNDEF, typically the program did something it shouldn't and you'd terminate it.
Thanks very much for your great help!!