Hi Feng,
This is standard practice for operating systems, hypervisors, and firmware running on Armv8-A systems. A key distinction between SPSel,#0 and SPSel,#1 is that you can tell which stack pointer you were using when you took an exception as they correspond to different offsets in the vector table. Often times, taking an exception from the same EL when using SPSel,#0 is non-terminal whereas taking an exception from the same EL when already using SPSel,#1 is considered terminal.
Take for example the scenario where your operating system, hypervisor, or firmware is running some task/thread code at EL1/EL2/EL3 and runs out of stack space, triggering a translation fault and attempting to stack some data (we’ll probably be using unmapped guard pages at the stack boundaries). The first thing the exception handler will try to do is stack the GPRs. If the reason you took the exception is because the stack pointed to by SP_EL1/2/3 has itself overflowed, this attempt to stack the GPRs will itself cause a translation fault and you’ll get stuck in a recursive exception.
In contrast, if the reason you took the exception is because the stack pointed to by SP_EL0 has overflowed, the exception handler will successfully stack the GPRs to the SP_EL1/2/3 stack and be able to diagnose + log what went wrong before rebooting gracefully.
Hope that helps, Ash.
From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Chen Feng via TF-A tf-a@lists.trustedfirmware.org Reply to: Chen Feng puck.chen@hisilicon.com Date: Friday, 17 April 2020 at 09:02 To: "tf-a@lists.trustedfirmware.org" tf-a@lists.trustedfirmware.org, Alexei Fedorov Alexei.Fedorov@arm.com, Yatharth Kochar Yatharth.Kochar@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com Cc: "puck.chen@hisilicon.com" puck.chen@hisilicon.com, "lizhong11@hisilicon.com" lizhong11@hisilicon.com Subject: [TF-A] sp select in atf
Hello all, I see the atf use different sp, and special for smc64 it use the sp_el0. So for the unhandled-exception handler, it must switch to sp_el0 to do the back-trace-dump. Since it default used sp_el3 when exception happen.
My question here is why using different sp in atf code? Just use the sp_el3 for all scenes seems more simpler.
Cheers, - feng
-- TF-A mailing list TF-A@lists.trustedfirmware.orgmailto:TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Thanks, this makes sense to me.
On 2020/4/17 16:45, Ash Wilding wrote:
Hi Feng,
This is standard practice for operating systems, hypervisors, and firmware running on Armv8-A systems. A key distinction between SPSel,#0 and SPSel,#1 is that you can tell which stack pointer you were using when you took an exception as they correspond to different offsets in the vector table. Often times, taking an exception from the same EL when using SPSel,#0 is non-terminal whereas taking an exception from the same EL when already using SPSel,#1 is considered terminal.
Take for example the scenario where your operating system, hypervisor, or firmware is running some task/thread code at EL1/EL2/EL3 and runs out of stack space, triggering a translation fault and attempting to stack some data (we’ll probably be using unmapped guard pages at the stack boundaries). The first thing the exception handler will try to do is stack the GPRs. If the reason you took the exception is because the stack pointed to by SP_EL1/2/3 has itself overflowed, this attempt to stack the GPRs will itself cause a translation fault and you’ll get stuck in a recursive exception.
In contrast, if the reason you took the exception is because the stack pointed to by SP_EL0 has overflowed, the exception handler will successfully stack the GPRs to the SP_EL1/2/3 stack and be able to diagnose + log what went wrong before rebooting gracefully.
Hope that helps,
Ash.
*From: *TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Chen Feng via TF-A tf-a@lists.trustedfirmware.org *Reply to: *Chen Feng puck.chen@hisilicon.com *Date: *Friday, 17 April 2020 at 09:02 *To: *"tf-a@lists.trustedfirmware.org" tf-a@lists.trustedfirmware.org, Alexei Fedorov Alexei.Fedorov@arm.com, Yatharth Kochar Yatharth.Kochar@arm.com, Sandrine Bailleux Sandrine.Bailleux@arm.com *Cc: *"puck.chen@hisilicon.com" puck.chen@hisilicon.com, "lizhong11@hisilicon.com" lizhong11@hisilicon.com *Subject: *[TF-A] sp select in atf
Hello all,
I see the atf use different sp, and special for smc64 it use the sp_el0.
So for the unhandled-exception handler, it must switch to sp_el0 to do
the back-trace-dump. Since it default used sp_el3 when exception happen.
My question here is why using different sp in atf code? Just use the
sp_el3 for all scenes seems more simpler.
Cheers,
- feng
--
TF-A mailing list
TF-A@lists.trustedfirmware.org mailto:TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
tf-a@lists.trustedfirmware.org
-
Ash Wilding -
Chen Feng