• State Accepted Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 349 subscribers
  • Views 11698 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

In aarch32 state, what is the mechanism to switch to aarch64 in software?

cray

Dear sirs,

I'm reading arm v8a specification. I found that when arm is in aarch32 state, only a few exceptions can switch to aarch64 depending on the configuration in the registers. the exceptions are as follows.

abort, physical async abort, physical FIQ and physical IRQ

while other exceptions are still processed in aarch32 state.

My questions are as follows.

Q1: Is my understanding correct?

Q2: If Q1 is yes, why these exceptions can be processed and others can not such as underfined instruction, svc, hvc?

Q3: What is the usage case for switch between aarch32 and aarch64?

In addition, exception return from higher exception level after reset can switch to aarch32, right?

cray

Parents
  • 0 Arm Employee Badge in reply to cray

    I should have been a little more precise.  Any exception type in AArch32 state could potentially lead to Execution state changing to AArch64.  No exception taken while in AArch64 will result in Execution state changing to AArch32.

    For exceptions returns the reverse is true.  An exception return in AArch64 might cause execution state to change to AArch32.  No exception return in AArch32 can lead to Execution state changing to AArch64(\*).

    For both exceptions and exception returns, a change of Execution state can only occur if there is also a change in EL.  That is an exception from EL0 to EL1 could lead to a change in Execution state.  But an exception from EL1 to EL1 could not.

    Let's take one example of an exception not on your list.  The pseudo code for the A32/T32 for SVC says:

    if ConditionPassed() then
  EncodingSpecificOperations();
  AArch32.CallSupervisor(imm32<15:0>);

    Following the chain down:

    AArch32.CallSupervisor(bits(16) immediate)
   ...
  if AArch32.GeneralExceptionsToAArch64() then
    AArch64.CallSupervisor(immediate);
  else
    AArch32.TakeSVCException(immediate);

    So based on on the return value of GeneralExceptionsToAArch64(), either the AArch32 or AArch64 pseudo code gets called.  Looking at GeneralExceptionsToAArch64():

    boolean AArch32.GeneralExceptionsToAArch64()
  return ((PSTATE.EL == EL0 && !ELUsingAArch32(EL1)) ||
          (HaveEL(EL2) && !IsSecure() && !ELUsingAArch32(EL2) && HCR_EL2.TGE == '1'));

    So the conditions for SVC are:

    * Taking SVC from EL0 to EL1, where EL1 is using AArch64 (defined by either SCR_EL3.RW or HCR_EL2.RW depending on Security state)

    * Taking SVC from NS.EL0/NS.EL1 when EL2 is using AArch64 (defined by SCR_EL3.RW) and HCR_EL2.TGE==1

    (\*) Well, maybe indirectly.  The exception return might trigger an exception, and the exception might cause a switch to AArch64.  But it is the exception, not the exception return, which is actually causing the Execution state change.

Reply
  • 0 Arm Employee Badge in reply to cray

    I should have been a little more precise.  Any exception type in AArch32 state could potentially lead to Execution state changing to AArch64.  No exception taken while in AArch64 will result in Execution state changing to AArch32.

    For exceptions returns the reverse is true.  An exception return in AArch64 might cause execution state to change to AArch32.  No exception return in AArch32 can lead to Execution state changing to AArch64(\*).

    For both exceptions and exception returns, a change of Execution state can only occur if there is also a change in EL.  That is an exception from EL0 to EL1 could lead to a change in Execution state.  But an exception from EL1 to EL1 could not.

    Let's take one example of an exception not on your list.  The pseudo code for the A32/T32 for SVC says:

    if ConditionPassed() then
  EncodingSpecificOperations();
  AArch32.CallSupervisor(imm32<15:0>);

    Following the chain down:

    AArch32.CallSupervisor(bits(16) immediate)
   ...
  if AArch32.GeneralExceptionsToAArch64() then
    AArch64.CallSupervisor(immediate);
  else
    AArch32.TakeSVCException(immediate);

    So based on on the return value of GeneralExceptionsToAArch64(), either the AArch32 or AArch64 pseudo code gets called.  Looking at GeneralExceptionsToAArch64():

    boolean AArch32.GeneralExceptionsToAArch64()
  return ((PSTATE.EL == EL0 && !ELUsingAArch32(EL1)) ||
          (HaveEL(EL2) && !IsSecure() && !ELUsingAArch32(EL2) && HCR_EL2.TGE == '1'));

    So the conditions for SVC are:

    * Taking SVC from EL0 to EL1, where EL1 is using AArch64 (defined by either SCR_EL3.RW or HCR_EL2.RW depending on Security state)

    * Taking SVC from NS.EL0/NS.EL1 when EL2 is using AArch64 (defined by SCR_EL3.RW) and HCR_EL2.TGE==1

    (\*) Well, maybe indirectly.  The exception return might trigger an exception, and the exception might cause a switch to AArch64.  But it is the exception, not the exception return, which is actually causing the Execution state change.

Children
No data