Smtp: trap handler push/pop fails for ECALLS

[christian-herber-nxp]

In contrast to other synchronous exceptions and interrupts, on ECALL you do not want to return to xepc but to xepc + 4. Otherwise you are returning to the ECALL itself and you are in an infinite loop.
I would propose adding epc to the argument registers written upon a synchronous exception.
It then does not have to be saved to the stack on entry.

[reosdev]

In case of ecall there are multiple registers (other than xepc) that are modified by ecall handler. Ecall calling convention defines up to 8 registers to pass parameters. 6 of 8 registers are included into the ACLIC trap stack frame. Creating exception for just one register makes little sense.

[christian-herber-nxp]

You are totally right.
Frankly, this makes me believe it might be smarter to limit the push/pop to interrupts only.
Separating interrupts and exceptions makes quite a bit of sense, as the handling is substantially different.

[christian-herber-nxp]

@reosdev I created a PR to limit push/pop to interrupt handlers. I think that is totally fine, and limits complexity quite a bit.

[reosdev]

Limiting the exception traps to use push/pop looks reasonable, but not universal. In case of OS, we can enter higher privilege with exception and leave it with interrupt (like it is done for cortex-m and context switch via SVC interrupt). This may happen every time ecall is used for calling OS service that triggers rescheduling.

I'm still think that context push/pop (especially hardware driven) is beneficial only for baremetal applications and has limited applicability in case of RTOS. So, it's probably better to limit this functionality by interrupt traps to M-mode (M/U-mode configurations at max), where it may be used without implicit overhead.

[christian-herber-nxp]

As I see it, interrupts that have RTOS interaction will likely be SW-vectored anyway. So much of this specification in general focuses on baremetal or direct interrupts in an RTOS (in Zephyr terminology).

[reosdev]

If context push/pop is driven by hardware (when we can get benefit of tail chaining), there is no choice. All interrupts (incl. those that are managed by OS) must use this. So, there are two choices:

• Make push/pop configurable for each interrupt (adds complexity to both HW and SW, still not generic).
• Prevent using context push/pop (at least HW version of it) for the cases where there is no benefits of it.
  As I see it, optimizing the average interrupt latency by degrading WCET (worst case execution time) is not good for real-time apps.

[christian-herber-nxp]

If context push/pop is driven by hardware (when we can get benefit of tail chaining), there is no choice.

Correct. But for SW-vectored interrupts, it is only the SW trampoline itself that will have the push/pop instruction, while the interrupt handlers are C-API functions, that are registered in a separate SW-vector table.

[reosdev]

This is correct. However, the root of the issue is in limited applicability of context push/pop for exceptions. I'm pointing to the case (HW push/pop and context switch via low priority interrupt) where the interrupts are used as exceptions. From one side, HW push/pop is beneficial for interrupts that are out of OS context. From other side, HW pus/pop limits the efficiency of dispatcher. As a result average latency is lower, but WCET is worse. So why I see this trap context optimization as very specific feature. Defining it for configurations bigger than M/U complicates architecture without obvious benefits (unless it's proven by experiments in simulation).

[christian-herber-nxp]

Why does this limit the efficiency of the dispatcher?

[reosdev]

To switch process context dispatcher needs:

• store previous process context from stack to memory (stored by HW to stack on tarp enter)
• restore new process context from memory to stack (will be recovered by HW from stack on trap leave)
  In other words, the stack is not right location for process context. If we cannot avoid saving process context to stack (like in case of hw push/pop), then we have to copy it twice on switch.

[christian-herber-nxp]

To switch process context dispatcher needs:

• store previous process context from stack to memory (stored by HW to stack on tarp enter)
• restore new process context from memory to stack (will be recovered by HW from stack on trap leave)
  In other words, the stack is not right location for process context. If we cannot avoid saving process context to stack (like in case of hw push/pop), then we have to copy it twice on switch.

I am lost. Which dispatcher are you talking about? Maybe you can reference some concrete zephyr snippets? I was thinking about the _isr_wrapper() function, which dispatches the SW-vectored interrupts. This could clearly use the ipush/ipop instructions to a benefit.

[reosdev]

I'm talking about the OS design that uses low priority interrupt (SVC in case of cortex-m) to switch process (task) context.

[christian-herber-nxp]

As discussed in the meeting, it would be helpful if you can add the permalink to the relevant code in zephyr here.

Also, as noted in the meeting, an alternative to fixing ecalls is making the stack layout normative, so that an ecall handler can fetch the arguments from the stack and also read/modify/write the epc.