Interrupt Handling recommendation and spurious IRQ debugging

Hi all,

I've seen in several implementations two different ways of Interrupt handling:

(i) Using a loop that handles several IRQs until IAR gets the ID of a special/spurious IRQ.
(ii) Handling one by one, and each IRQ performs an kernel/hypervisor exit.

Q1: I would like to get your insight on what is the recommend way of a sw implementation running on ARMv8 with GICv3.

Today, we are using the option (ii) and we are getting some spurious IRQs, we actually dont know what is the root cause. We would like to know if the spurious IRQ is legitime or we are doing something wrong there.

Q2: In our setup, we use only SGIs and PPIs. Do you know a case where these two types of IRQs can trigger spurious IRQs?

I see in the spec the following:

• " This value is returned in response to an interrupt acknowledge, if there is no pending interrupt with
     sufficient priority for it to be signaled to the PE, or if the highest priority pending interrupt is not
     appropriate for the:
     
  
  1. Interrupt group that is associated with the sysreg
  2. Current Security state

Q3: For (1) I udnerstand, if a group0 IRQ has higher prioritiy and sw tries to acknowledge it using ICC_IAR1_EL1, is it?

(1) is not our case, since we only deal with group 1 IRQs. What about (2): If the TZ secure world is using IRQs in the secure side, does this has any side effect on the non-secure side, even when the group0 IRQs are disabled?

Q4: Do you guys suggest any good way do debug the root cause of spurious IRQs?

Thanks,
Jorge