Tpush should pass major and minor interrupt identity to handlers

[christian-herber-nxp]

Currently, an external interrupt receives the minor identity in a0. This works for HW-vectored interrupts.

For SW vectored interrupts, it is important to also pass the major identity, so that the dispatcher can call the driver of the external controller.

I propose to change external interrupts to receive in
a0: major identity
a1: minor identity

[reosdev]

Passing arguments in a0/a1 conflicts with SBI specification that uses this registers to pass the environment call arguments and return values. E.g., ecall trap is similar to function call and any kind of the automatically saved trap frame contradicts with it.

[christian-herber-nxp]

Passing arguments in a0/a1 conflicts with SBI specification that uses this registers to pass the environment call arguments and return values. E.g., ecall trap is similar to function call and any kind of the automatically saved trap frame contradicts with it.

Fair point. How relevant do you see this in the field we would be deploying ACLIC?

There are two possibilities for tpush:

1. We have a simple, generic push sequence, that does a minimal useful set of actions
2. We build a complex tpush, that takes different actions depending on which kind of interrupt we have and what exception code is seen.

[reosdev]

Fair point. How relevant do you see this in the field we would be deploying ACLIC?

It took some time to convert a filling to text.

My understanding that M/S/U configuration should use the SBI-like abstraction. This extremely simplifies application porting efforts and keeps the room to isolate application at the system level (initial intend of M-mode firmware). Otherwise I don't see the right purpose to have more than one privileged mode. If this assumption is correct, then there is no other way to establish S-to-M communication except ecall (or any other trap). This use case splits the exception traps into two groups:

• Not expected traps (errors): trap context is important to identify cause of the problem and solve it.
• Expected traps (calls with privilege elevation): like other function calls there are no need to worry about the system state, just standard calling conventions.

Simple M/U configuration may use other exception traps in ecall manner. For example instruction simulation (illegal instruction exception) implicitly uses general purpose registers to pass and/or return the parameters.

The exception trap context push/pop may help with nested traps but is absolutely useless in 99,99% cases (nested traps are always errors). From other side there is DT extension that isolates context of nested trap. Considering this I think that trap stack frame push/pop should not be applied to exception traps (as well as for NMIs that are asynchronous exceptions).

[christian-herber-nxp]

I have been thinking about this and it might be reasonable to just stack a few GPRs to allow tail chaining and late preemption, but to leave all the CSR handling to the handlers. This looses a couple of cycles in latency, but you win flexibility

A few saved registers are also beneficial for handling recalls.

[reosdev]

I don't think that stacking few GPRs may helps in case of exception traps. Tail chaining is not achievable for exceptions as synchronous non-maskable event cannot wait for completion of the previous handler. Late preemption is also not for exceptions, as any trap in exception context is the double fault.

[christian-herber-nxp]

It helps in the sense that the handler would anyway want to stack some registers.
If you split this, and have a different behavior for exceptions and interrupts, than this does not work when both have the same entry point.
If you make it interrupts only, we have to put a big asterix on this that it is incompatible with any configuration in which an exception and an interrupt can trap to the same code. Avoiding such complications is beneficial.

It is all one huge trade-off at the end of the day. There will not be one objectively best solution, which is why it is difficult to narrow down on one.

[reosdev]

It helps in the sense that the handler would anyway want to stack some registers.

Exception handlers may require specific (different for each particular exception) stack frame. How the stack frame can be unified for all these cases? For example the ecall handler may stack no one single register (this is simple function call where compiler takes care about registers).

If you split this, and have a different behavior for exceptions and interrupts, than this does not work when both have the same entry point.

In case of shared trap entry the interrupt late preemption and tail chaining works natively. In most cases there is the loop inside that calls handlers until there is top pending interrupt (context will be saved/restored once for all chained interrupts, no hardware support is required). For exception traps nothing like late preemption/tail chaining is feasible neither in legacy direct/vectored modes nor in new nested vectored mode. Nothing can delay or prevent exception to trap, including other exceptions at any handling stage.

If you make it interrupts only, we have to put a big asterix on this that it is incompatible with any configuration in which an exception and an interrupt can trap to the same code. Avoiding such complications is beneficial.

Backward compatibility is as simple as nothing. Interrupt controller just must provide support for classic/legacy trap handling modes. Nested vectored interrupts handling is different story and cannot be compatible with any existing software. In such case separating exceptions and interrupt traps is quite reasonable.

[christian-herber-nxp]

It helps in the sense that the handler would anyway want to stack some registers.

Exception handlers may require specific (different for each particular exception) stack frame. How the stack frame can be unified for all these cases? For example the ecall handler may stack no one single register (this is simple function call where compiler takes care about registers).

If you look e.g. at Zephyr, all exceptions share the same stack frame. As exceptions are not vectored, you will first need to identify the type of exception, do whatever the OS requires you in addition, and then jump to the handler.

If you split this, and have a different behavior for exceptions and interrupts, than this does not work when both have the same entry point.

In case of shared trap entry the interrupt late preemption and tail chaining works natively. In most cases there is the loop inside that calls handlers until there is top pending interrupt (context will be saved/restored once for all chained interrupts, no hardware support is required). For exception traps nothing like late preemption/tail chaining is feasible neither in legacy direct/vectored modes nor in new nested vectored mode. Nothing can delay or prevent exception to trap, including other exceptions at any handling stage.

I would not call what you described late preemption or tail chaining. It is another level of efficiency built into the trampoline. Also, not sure how that is related to my point that it will be difficult to have a different behavior between exceptions and interrupts.

If you make it interrupts only, we have to put a big asterix on this that it is incompatible with any configuration in which an exception and an interrupt can trap to the same code. Avoiding such complications is beneficial.

Backward compatibility is as simple as nothing. Interrupt controller just must provide support for classic/legacy trap handling modes. Nested vectored interrupts handling is different story and cannot be compatible with any existing software. In such case separating exceptions and interrupt traps is quite reasonable.

In my eyes, a feature is a good feature that will stand the tests of time if it is widely applicable. If it is already incompatible with everything out there, it may also be incompatible with future developments.
Agree that separating traps into extensions and interrupts is reasonable for our purposes.
The current spec reflects that.

[reosdev]

If you look e.g. at Zephyr, all exceptions share the same stack frame. As exceptions are not vectored, you will first need to identify the type of exception, do whatever the OS requires you in addition, and then jump to the handler.

This is correct description of exception handling in Zephyr. Can you describe the case when ACLIC-style stack frame may help (improve) the Zephyr's way to handle exceptions?

I would not call what you described late preemption or tail chaining. It is another level of efficiency built into the trampoline.

In fact the shared handler with loop inside does exactly the same (just in SW) as the late preemption (claims top interrupt as late as possible) and tail chaining (does not restore trap context until there is pending interrupt).

Also, not sure how that is related to my point that it will be difficult to have a different behavior between exceptions and interrupts.

I don't understand your point. What difficulty are you mentioning?

In my eyes, a feature is a good feature that will stand the tests of time if it is widely applicable. If it is already incompatible with everything out there, it may also be incompatible with future developments.

I'm getting lost. Please point me to the SW that is compatible with current ACLIC nested vectored interrupts, late preemption, tail chaining, and interrupt/exception stack frame?

Agree that separating traps into extensions and interrupts is reasonable for our purposes. The current spec reflects that.

My point is that trap stack frame definition should be limited by interrupt traps only. Exception trap stack frame should be out of ACLIC specification scope as it has no benefits for existing SW and there is no clear scenario where it can be potentially beneficial.

[christian-herber-nxp]

This is correct description of exception handling in Zephyr. Can you describe the case when ACLIC-style stack frame may help (improve) the Zephyr's way to handle exceptions?

less registers need to be stacked, because some are prestacked
registers like mstatus are already in CSR, thus you can avoid an additional read

[reosdev]

less registers need to be stacked, because some are prestacked
registers like mstatus are already in CSR, thus you can avoid an additional read

These arguments are weak. Reading register like mstatus is ONE instruction. SW does the same with same efficiency and better flexibility (set of registers depends on implementations). This (exception trap wrapper) needs to be implemented once per application. The only thing that may add value is the SP management. I still not convinced that any exception stack frame is needed.

[christian-herber-nxp]

I never argued it is needed for exceptions. We need it for interrupts because we need late preemption and tail chaining.
Next question is what is the cleanest most compatible path towards that.

[reosdev]

I never argued it is needed for exceptions. We need it for interrupts because we need late preemption and tail chaining.

So, now we are aligned. Unified stack frame is required for nested vectored interrupts to enable late preemption and tail chaining, which is not applicable for exception traps. Discussion about exception stack frame content can now be closed. Exception trap stack frame is always software defined.

Next question is what is the cleanest most compatible path towards that.

The path is straight forward. We need to define three types of execution contexts: exception, interrupt, and normal execution context. If this is feasible (I think it is), then we have clear rules on what to do at execution context switching.

[christian-herber-nxp]

The path is straight forward. We need to define three types of execution contexts: exception, interrupt, and normal execution context. If this is feasible (I think it is), then we have clear rules on what to do at execution context switching.

I am not sure why that is needed, but RISC-V explicitly chose to make non-handler mode indistinguishable from handler mode.