why the inter-core SGI interrupt cannot be trigged on GICv3 hardware

moonlight wrote:

Did you also write GICR_IGROUPR0 to set the interrupt as NS.G1?  (Note, you'll need to do this in Secure state)

- No, I didn't, because the core is running in 32 bit hyp mode.  But, even so, if everyghing is ok, core 1 will receive a SGI either in group0 or group1, actually core1 see nothing.

The sender indicates the Group (G0, S.G1, NS.G1) of interrupt it wants to send by which SGI register it writes.  The Group the sender specified has to match how the receiver(s) have configured that interrupt in their GICR_IGROUPR0/GICR_IGRPMODR0 registers.  If they don't, no interrupt is generated.

Take a look at Table 11 in the GICv3 app note for a fuller explanation:

GICv3 Software Overview

moonlight wrote:

Did you also write GICR_IGROUPR0 to set the interrupt as NS.G1?  (Note, you'll need to do this in Secure state)

- No, I didn't, because the core is running in 32 bit hyp mode.  But, even so, if everyghing is ok, core 1 will receive a SGI either in group0 or group1, actually core1 see nothing.

The sender indicates the Group (G0, S.G1, NS.G1) of interrupt it wants to send by which SGI register it writes.  The Group the sender specified has to match how the receiver(s) have configured that interrupt in their GICR_IGROUPR0/GICR_IGRPMODR0 registers.  If they don't, no interrupt is generated.

Take a look at Table 11 in the GICv3 app note for a fuller explanation:

GICv3 Software Overview

Pretty much.

When GICD_CTLR.DS==0, only secure software can access GICR_IGROUPR0 (or GICD_IGROUPRn).  So you would need to program Secure software to program these registers, typically before entering Non-secure state for the first time.

Hi Martin,

In my environment, GICD_CTLR.DS is 0.

The value of GICR_IGROUPR0 is always 0 and I cannot reconfigure it. I think this is because cores are in non-secure state, So does this mean the receiver core will always treat this as a group0 SGI?  And according to the document you mention(table 11), a group0 SGI won't be forwarded if the GICR_NSACR is not set correctly in secure state.

So, with the current configuration in non-secure state, I cannot send a SGI from one core to another, is this correct?

Got it. Thank you so much.

Hi Martin

I set GICD_CTLR as 0x47 in secure state. I.e, DS is 1.

Now in my 32bit hyp mode, the value of GICR_ISENABLER0 is 0x300, GICR_IGROUPR0 is 0xffff, GICR_IGRPMODR0 is 0. But I still cannot send out a #8 SGI using icc_sgi1r or GICD_SGIR.

The other SPI interrupt, say timer, works fine in the system.

Do you have any other ideas about this issue?

Thanks.

Couple of questions.

Are you doing this write from Secure state?  If so, I would suggest just writing GICR_IGROUPR0 and not setting DS==1.  If not, you can't set the DS bit from Non-secure state.

Also, you don't appear to be setting the ARE bits.  The ARE bits select between the GICv3 and legacy mode.  If you're setting the SRE bits, then the ARE bits should also be set.

EDIT: For reference, attached is a simple assembler program I wrote once to test something.  It's a very minimal GICv3 set up sequence, targeting the Base Platform model.