• State Accepted Answer
  • Replies 2 replies
  • Subscribers 140 subscribers
  • Views 5760 views
  • Users 0 members are here
Options
Related
How was your experience today?

What will happen if one core sends SGI interrupt to another core quickly and continuously？

geekfolk

I am doing this on GICv2 controller: send SGI interrupt from core0 to core1 quickly and continuously. It looks that some interrupts are missing in core1

It seems that ARM does not provide guidance in processor or GIC's TRM to describe what will happen under such circumstances, could anyone help to confirm?

Thanks!

Parents
  • 0

    The short answer is that instances of the interrupt will be merged.

    GICv1/v2: SGIs are banked by source and destination.  That means if cores A and B both send SGI 5 to core C, C will see two SGIs.  The sender's ID (A and B in the example) are prefixed to the interrupt ID to allow the receiver to tell them apart.

    Your scenario is a little different, core A is repeatedly sending the same SGI to core C.  There is only 1 bit to record that SGI 5 is pending on C from A.  Therefore if A sends a second SGI 5 to C before the first is consumed, there is no ability to "count" the number of instances.  It is either pending or it is not.  Therefore C only receives one interrupt.  This is usually referred to as "merging".

    The way this expected to be used is that interrupt tells C that there is something in a buffer.  C goes read the buffer when it gets the interrupts.  With the routine being able to handle there being multiple things in that buffer.  Therefore if the interrupts are not merged it doesn't matter, as the software will spot the multiple items.

    GICv3/v4: Is similar, but a little different. SGIs are not banked by sender.  Therefore in the first example (where A and B send SGI 5 to C), the interrupts could also have been merged.

Reply
  • 0

    The short answer is that instances of the interrupt will be merged.

    GICv1/v2: SGIs are banked by source and destination.  That means if cores A and B both send SGI 5 to core C, C will see two SGIs.  The sender's ID (A and B in the example) are prefixed to the interrupt ID to allow the receiver to tell them apart.

    Your scenario is a little different, core A is repeatedly sending the same SGI to core C.  There is only 1 bit to record that SGI 5 is pending on C from A.  Therefore if A sends a second SGI 5 to C before the first is consumed, there is no ability to "count" the number of instances.  It is either pending or it is not.  Therefore C only receives one interrupt.  This is usually referred to as "merging".

    The way this expected to be used is that interrupt tells C that there is something in a buffer.  C goes read the buffer when it gets the interrupts.  With the routine being able to handle there being multiple things in that buffer.  Therefore if the interrupts are not merged it doesn't matter, as the software will spot the multiple items.

    GICv3/v4: Is similar, but a little different. SGIs are not banked by sender.  Therefore in the first example (where A and B send SGI 5 to C), the interrupts could also have been merged.

Children