arch: arm64: interrupt test is failing

[carlocaione]

The interrupt test scans the _sw_isr_table[] trying to find the first not allocated vector to dynamically install a new ISR. This fails on Cortex-A and Cortex-R because of at least 3 different issues.

First of all let's see how the _sw_isr_table[] is structured on these platforms:

             _sw_isr_table[]
     +----------------------------+   ^
     |                            |   |
     |                            |   |
     |                            |   |
     |                            |   |
     |           SPI ISR          |   |
     |                            |   |
33   |                            |   |
     +----------------------------+   |
32   |                            |   |
     |                            |   |
     |                            |   |
     |           PPI ISR          |   |
     |                            |   |
17   |                            |   |
     +----------------------------+   |
16   |                            |   |
     |                            |   |
     |                            |   |
     |           SGI ISR          |   |
     |                            |   | 2nd level (cascade)
 1   |                            |   |
     +-------------------------------------------------------
 0   |           GIC ISR          |   | 1st level
     +----------------------------+   v

_sw_isr_table[0] is the GIC ISR called every time an interrupt is triggered. In the GIC ISR the IRQ line number is retrieved from the GIC registers and the correct ISR from the 2nd level is called.

We have at least 3 problems:

• z_isr_install() is using irq_is_enabled() to check if the IRQ is enabled. The arch_irq_is_enabled() code is currently returning always 1, triggering the assert __ASSERT(!irq_is_enabled(irq)) because supposedly it is not possible to have the IRQ enabled without the relative ISR installed.
• Another issue is that the SGIs in the GIC are supposed to be enabled (and are enabled at init time) even though there is no ISR installed. So triggering the assert again.
• z_isr_install() is assuming that there is an identity mapping (at most shifted by CONFIG_GEN_IRQ_START_VECTOR) between the IRQ number and the table index. This is not always the case, especially when cascade interrupt controllers are present. For example in our case all the arch_irq_* routines are using an IRQ number that is shifted as ($irq + 1) << 8. This implementation is taken from the Cortex-R code to identify the IRQs on the 2nd level interrupt controller. The IRQ number is shifted back before entering the GIC code and pointing to the correct index in the _sw_isr_table table.

I have a patch downstream that is able to make the test passing but while the first 2 points are somehow easily addressable I haven't found a non-ugly way to fix the third point. That said the whole IRQ management code will be reworked for Cortex-R in #19698 and then adopted by Cortex-A using a shared code-base so I suggest to ignore for now this issue.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.