This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[ARM GICv3 - GIC Stream protocol] An interrupt being retrieved from a CPU interface!

Hi all,

I am investigating the GIC Stream protocol and having a confusing issue as the title.

The figure below shows the case that an interrupt is retrieved from CPU interface.

As explained in the GIC Stream Specification, there may be 2 reasons:

1. The relevant group enable in GICD_CTLR is cleared by software (I can understand it).

2. The pending interrupt is configured to use the 1-of-N model, and the IRI selects a different target PE.

For the second reason, because an interrupt (SPI) is sent to a target PE only, instead of being broadcasted to all PEs that share the interrupt,

only the redistributor that connects to the PE should send the Set x Command to CPU interface. Therefore, this reason seems unreasonable as my understanding.

Anyone can make this explanation clear?

Thank you.

Parents
  • When an SPI is configured as 1-of-N, when the interrupt becomes pending the GIC will select one of the available cores and forward the interrupt to that core.  How the GIC selects the target is down to the implementation, and might change every time the interrupt becomes pending.

    Now, imagine that we pick core X and forward the interrupt to that core.  It's possible that core X just does not handle the interrupt.  It might be busy, it might have the PSTATE masks bits set, etc...  Seeing that the interrupt is not being activated the GIC _could_ decide to retrieve the interrupt from core X and send it to core Y instead.

Reply
  • When an SPI is configured as 1-of-N, when the interrupt becomes pending the GIC will select one of the available cores and forward the interrupt to that core.  How the GIC selects the target is down to the implementation, and might change every time the interrupt becomes pending.

    Now, imagine that we pick core X and forward the interrupt to that core.  It's possible that core X just does not handle the interrupt.  It might be busy, it might have the PSTATE masks bits set, etc...  Seeing that the interrupt is not being activated the GIC _could_ decide to retrieve the interrupt from core X and send it to core Y instead.

Children
No data