CA72 can't access ICC_IAR1_EL1 at EL1

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_S
SCR_EL3 is 0xc0e  // checking SCR_EL3.NS, which is 0x0 by default after initialization

SCR_EL3 is 0xc0f   // setting SCR_EL3.NS to 0x1
icc_sre_el1 is 0x7   // checking ICC_SRE_EL1_NS

HCR_EL2 is 0x0   // Got HCR_EL2 0x0, cause I read it at EL3
ICC IAR1 EL1 is 0x3ff    // checking ICC_IAR1_EL1

enter non-secure world
transition_to_lower_el :Current EL is EL2
transition_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_0
EXC number:0x00000018
EXC class: 0x00000018
FaultReg: 0x00000000
StatusPrg: 0x60000004
PC: 0x00000000 0xA0007DCC
FaultReg: 0xD538CC00
StatusPrg: 0x00303019
Exception class is MSR_MRS
These report exceptions from MSR, MRS, or System instructions
Instruction syndrome MSR/MRS:
Op0: 0x00000000
Op2: 0x00000000
Op1: 0x00000000
CRn: 0x00000000
Rt : 0x00000000
CRm: 0x00000018
dir: 0x00000001

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_S
SCR_EL3 is 0xc0e  // checking SCR_EL3.NS, which is 0x0 by default after initialization

SCR_EL3 is 0xc0f   // setting SCR_EL3.NS to 0x1
icc_sre_el1 is 0x7   // checking ICC_SRE_EL1_NS

HCR_EL2 is 0x0   // Got HCR_EL2 0x0, cause I read it at EL3
ICC IAR1 EL1 is 0x3ff    // checking ICC_IAR1_EL1

enter non-secure world
transition_to_lower_el :Current EL is EL2
transition_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_0
EXC number:0x00000018
EXC class: 0x00000018
FaultReg: 0x00000000
StatusPrg: 0x60000004
PC: 0x00000000 0xA0007DCC
FaultReg: 0xD538CC00
StatusPrg: 0x00303019
Exception class is MSR_MRS
These report exceptions from MSR, MRS, or System instructions
Instruction syndrome MSR/MRS:
Op0: 0x00000000
Op2: 0x00000000
Op1: 0x00000000
CRn: 0x00000000
Rt : 0x00000000
CRm: 0x00000018
dir: 0x00000001

Hi Martin,

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 0x7
icc_sre_el3 is 0x7

SCR_EL3 is 0xc0e

SCR_EL3 is 0xc0d
icc_sre_el1 is 0x7
ICC IAR1 EL1 is 0x3ff
enter non-secure world
transition_to_lower_el :Current EL is EL2

HCR_EL2 is 0x0
transition_to_lower_el :Current EL is EL1

current EL is 0x4
ICC 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:

• Are you setting up ICC_SRE_EL2.SRE before ICC_SRE_EL1(NS)?
• Do you have ISBs between changing SCR_EL3.NS and accessing the different ICC_SRE_EL1s?
• To which EL is the exception being taken? (I was assuming EL1!)
  • If it's being taken to EL2, you also need to check how ICH_HCR_EL2.TALL1 is configured.
• The Op0/Op1/Op2/CRn/CRm values reported don't match ICC_IAR1_EL1.  Have you sanity checked that's the instruction actually being executed?

Hi Martin,

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.

Hi Martin,

Thanks very much for your great help!!