What is all possible SGI miss scenario?

To add...

There are also lots of reasons an SGI might be successfully registered but not cause an interrupt exception on the target CPU.  For example, the SGI might be individually disabled, it might be lower priority than an interrupt already being handled, the CPU might interrupts masked... 

To add...

There are also lots of reasons an SGI might be successfully registered but not cause an interrupt exception on the target CPU.  For example, the SGI might be individually disabled, it might be lower priority than an interrupt already being handled, the CPU might interrupts masked... 

Thank you Martin for prompt reply.

Any idea about below scenario

system wakeup(wakeup core 0) --> hotplug of secondary core -->  primary core 0 send SGI to secondary core 1.

Here SGI missed. What will be possible reason

I'm not very knowledge-able about the specifics of hot plug/wake-up... so I'll stick to the GIC side.

My starting point would be to check if the GIC has registered the SGI as being pending for the receiving CPU.  Knowing that will tell you which side the problem is on.

GICR_ISPENDR0 holds the pending state for SGIs.  This is a Redistributor register, and you need to check the Redistributor of the receiver.  Ideally start before the SGI is sent, checking that the SGI isn't yet pending.  Then send the SGI and see if the pending bit gets set.

If GICR_ISPENDR0 shows the SGI as pending, the interrupt reached the Redistributor and was registered.  If not, then either the SGI didn't reach the Redistributor or the Redistributor dropped it.

If the SGI is NOT shown as pending:

• Check the target information
  • What affinity does GICR_TYPER on the target Redistributor report?
  • What value (affinity and IRM) was written to the ICC_SGI register on the sender?
• Check the Group:
  • What Group (G0, NS.G1, S.G1) is the SGI assigned to on the receiver? (GICR_IGROUR0 and GICR_IGRPMODR0)
  • Which ICC_SGI register was written on the sender?  And what Security state was the sender in at the time?

If the SGI is pending: the interrupt was registered by the GIC:

• Is the SGI individually enabled? (GICR_ISENABLER0)
• What priority is assigned to the interrupt? (GICR_IPRIORITYR0)
• Is the Group the SGI is assigned to enabled?
• Is the link between Redistributor and CPU inline? (GICR_WAKER)

The last one (GICR_WAKER) is interesting and comes down what is meant to happen on the SGI being sent.  As I said, I'm not familiar with the hot plug side flows.  If the link is offline, then the GIC will raise a wake-request for the CPU (which is a signal, probably to a power controller).  If the link is online, the GIC should be sending the SGI (modulo Enable, Priority, Group...) to the CPU.

Of course, it might not be a GIC problem, it might be related to software/firmware.  But it's worth checking the GIC is at least registering the interrupt.

"If the link is offline, then the GIC will raise a wake-request for the CPU (which is a signal, probably to a power controller)" 

in case of link offline , Does SGI in Pending state? 

Yes.  The link being online/offline affects what the Redistributor does in response to an interrupt becoming pending (forward to the CPU vs raise wake request).  It doesn't change whether the interrupt is recorded as pending or not.

Thank you so much for detailed explaination.

One Last question .

In my system, Redistributor is powering up/making online using waker register.

Suppose core 0 redistributor is online and core 1 redistributor is offline. SGI sent from core 0 to core 1. After that core 1 redistributor online using waker register, does SGI forward to the core 1? meaning is SGI in pending state ?

Thank you in advance for your time and help