Xtensa High priority INT interrupt window exception causes STACK ERROR

[hongshui3000]

Describe the bug
The zephyr xtensa architecture does not seem to take this situation into consideration:
For example, the excption interrupt level is less than the highest priority interrupt. When the high priority interrupt preempts the window exception interrupt (such as WindowOverflow8), the entire stack will be destroyed


L4 and L5 interrupts will be able to interrupt WindowOverflow8 interrupts, at this time Zephyr's interrupt handler does not do any special processing
Related instructions in freertos：

HIGH PRIORITY (LEVEL > XCHAL_EXCM_LEVEL) INTERRUPT VECTORS AND HANDLERS
High priority interrupts are by definition those with priorities greater
than XCHAL_EXCM_LEVEL. This includes non-maskable (NMI). High priority
interrupts cannot interact with the RTOS, that is they must save all regs
they use and not call any RTOS function.
A further restriction imposed by the Xtensa windowed architecture is that
high priority interrupts must not modify the stack area even logically
"above" the top of the interrupted stack (they need to provide their
own stack or static save area).
Cadence Design Systems recommends high priority interrupt handlers be coded in assembly
and used for purposes requiring very short service times.
Here are templates for high priority (level 2+) interrupt vectors.
They assume only one interrupt per level to avoid the burden of identifying
which interrupts at this level are pending and enabled. This allows for 
minimum latency and avoids having to save/restore a2 in addition to a0.
If more than one interrupt per high priority level is configured, this burden
is on the handler which in any case must provide a way to save and restore
registers it uses without touching the interrupted stack.
Each vector goes at a predetermined location according to the Xtensa
hardware configuration, which is ensured by its placement in a special
section known to the Xtensa linker support package (LSP). It performs
the minimum necessary before jumping to the handler in the .text section.

In fact, it seems that Zephyr does not support high-priority interrupts, but is there any reminder or explanation

[andyross]

Looking at this for the first time. I'm sorry, I don't understand what you want Zephyr to do here? We took an exception, it got preempted by an interrupt that Zephyr doesn't manage and landed in a handler with code written by the application.

How does Zephyr prevent the application code from breaking Zephyr state? You need to write your custom interrupt handlers to be safe when they preempt important things like window exceptions.

I understand that's extremely difficult. During a window exception you don't have (and probably can't recover reliably) a stack pointer. But it's not impossible. Grab a SR that isn't in use (we have a brand new feature to help you with this) and do a musical chairs entry to carefully save off the GPR state. And needless to say the resulting exception code needs to be built to the CALL0 ABI, or be written entirely in assembly.

But it's not Zephyr's problem to solve. The interrupts we emit code for work reliably.

[hongshui3000]

@andyross
I can understand what you're saying,

1. the issue is that people porting xtensa arch or people using xtensa may encounter this problem.
2. This should be classified as a problem with xtensa arch. If the code implementing high priority interrupts will need to call the underlying code of the current architecture (such as thread switching, etc.), if every ordinary user using high priority calls the underlying code It will be risky.
3. The interrupt registration function "IRQ_CONNECT(DT_INST_IRQN(0), DT_INST_IRQ(0, priority), i2c_my_isr, DEVICE_DT_INST_GET(0), 0)" in zephyrrtos will register any priority interrupt to the current interrupt code, and currently The code is actually unable to support high priority interrupts. If the user does not notice, it will cause rtos to crash, and it will crash randomly (interruption is random), which is difficult for ordinary people to solve

I think currently zephyrrtos should at least deny xtensa high priority interrupt registration or alert the user, or improve xtensa arch to meet high priority interrupt registration

[andyross]

Agreed, let's mark this as an enhancement instead of a bug. Zephyr does not currently support applications registering interrupts that interrupt exception handlers. Applications that do so need to be coded very carefully. It would be good if Zephyr had an answer here, but it doesn't. We should add that as a feature.

[hongshui3000]

agree completely