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

ARMv8 exception vector significance of EL0_SP

Hi,   I am new to ARMv8 architecture and while reading the v8 exception vectors I am not able to understand significance of adding SP_EL0 level vectors while SP_ELx vector set exists. What I am trying to find a use case where this is useful. I understand that when the exception is taken at same level by default the stack of same exception level is used for example if EL2 (Hyp) mode is defined then if exception occurs while being at EL2 level the stack defined at EL2 will be used but not sure if I configure to use EL0 level stack under what use cases this could be useful ? Can some one give a use case and explain ?  Also while going through the spec it seems these two different stack usage idea is taken from Cortex-M architecture but i am not very clear with thread and handler modes as well. Can any one explain it ?  Just wanted to add here that ARMv7 doesn't have thread and handler concept so i am not clear requirement in ARMv8. Also in ARMv7 my understanding is that stack pointer for exceptions eg. if IRQ occurs in Hyp mode then banked IRQ_SP is used so no need to specify the SP.

Thanks

  • I think there are a few parts to this

    Firstly I very much suppose the ARMv8 architecture will be used in embedded controllers like the M series and they want as far as possible a uniform architecture that can deal with both even if the embedded one will be a subset. With this one can accurately emulate the action even if tail chaining won't be as efficiently done by software as the hardware does for M series.

    Secondly the EL0 stack pointer does not have to be the stack pointer used at user level - the first interrupt handler going from user level can change what it points to rather than risk the user causing problems by what they point their stack pointer at and change it back on return.

    Thirdly interrupts that are particular to the process like system calls and virtual store interrupts can be handled from the process stack whilst I/O interrupts that can happen in any VM are handled on the main interrupt stack, this makes it easier to abandon a VM even if it is in the middle of a system call.

    All this can be done without this mechanism in other ways but this is a good clean and general way of doing things.