In the manual of arm-v8a, it mentions that the debug exceptions could be routed to EL1 or EL2. However, i don't really want to implement EL2 on Juno, so is there anyway to route these exceptions to EL3?
Thanks for any help!
Hi, breakpoint exceptions taken from EL3 will be routed to EL3 but all other types of debug exception will always be routed to either EL1 or EL2. There is no way to make EL3 be ELD.
Hope that helps,
Ash
Thanks, Ash!
Other than debug exceptions, i found that only very few synchronous exceptions (like traps) could be routed to EL3. May i know the reason for the design? For security concerns or for something else?
Best Regards,
Zhenyu
Hello Zhenyu,
No problem
The simple answer is because it wouldn't make sense.
Only the OS knows what to do when an application accesses a virtual address where the translation table entry doesn't have the AF bit set, as this behaviour is specific to that OS (perhaps the OS implements lazy memory allocation).
Only the OS knows what to do when an application attempts to access an unmapped virtual address, as this behaviour is specific to that OS (perhaps the OS kills the application with a segmentation fault signal).
Only the OS knows what to do when an application makes a service call using SVC, as the available service calls are specific to that OS.
Only the Hypervisor knows what to do when a guest OS makes a service call using HVC, as the available service calls are specific to that Hypervisor.
And so on.
Traps are different because they're a way for more privileged ELs to restrict/monitor/emulate the behaviour of less privileged ELs. An example of this would be the SCR_EL3.TWI bit, which traps WFI instructions executed at EL0/EL1/EL2 to EL3.
Asynchronous exceptions (IRQ/FIQ/SError) are different again; SErrors, for example, represent highly system specific errors. The firmware is probably best placed to deal with these, as the firmware is tightly coupled to the system and will know what to do, therefore a typical use case is to route SErrors to EL3.
Similarly we can configure the interrupt controller (such as the GIC-500) to signal interrupts meant for the current security state as IRQs, and to signal interrupts meant for the *other* security state as FIQs. We can then route FIQs to EL3; the firmware will query the GIC for the interrupt, get a special INTID indicating that there's an interrupt meant for the other security state, and will therefore perform a world switch.
Ash.
Appreciate for your patient and the details, Ash! That does make sense, maybe i should not try to monitor the synchronous exceptions of other ELs in EL3.
View all questions in Arm Development Platforms forum