GIC-v3&4: Regarding the Acknowledge Register

Hi all,

I need some clarification related to acknowledge register in GICv3&4 document.

----------------------------------------------------------------------------------------------------------------

8.13.11 GICC_IAR, CPU Interface Interrupt Acknowledge Register:

-->In GIC implementations that support two Security states, if the highest priority pending interrupt is

     in Group 0, Non-secure reads return the special INTID 1023.

-->In GIC implementations that support two Security states, if the highest priority pending interrupt is

     in Group 1, Secure reads return the special INTID 1022.

----------------------------------------------------------------------------------------------------------------

highest pending priority interrupt -- HPPI (abbreviated by me for convenience).

Group 0 -- G0

Group 1 -- G1

Doubt:

In the above given statements it is said that if HPPI is G1, secure read returns INTID 1022..

Q1) If HPPI is G1 and if Non-Secure read is made to register, Does this register(GICC_IAR) return the valid INTID..?

Q2) If answer is YES to above question then, in what scenario do we use GICC_AIAR register.?

Page - 531

-------------------------------------------------------------------------------------------------------------------------

             8.13.4 GICC_AIAR, CPU Interface Aliased Interrupt Acknowledge Register

                        The GICC_AIAR characteristics are:

                         Purpose

                              Provides the INTID of the signaled Group 1 interrupt. A read of this register by the PE acts as an

                                  acknowledge for the interrupt.

-------------------------------------------------------------------------------------------------------------------------

In document it is mentioned that we can access this register either in secure/Non-Secure mode.

Q3)  Does this register return valid INTID on accessing it through Secure read

Above mentioned questions are as per my understanding, please correct me if i am wrong.

I will be very happy if you can give me clear explanation related this register operation.

Thanks,

Rakesh.

  • Hi,

    Firstly, note that the memory mapped CPU interface registers that you mentioned (GICC_IAR and GICC_AIAR) are only used in Legacy mode. When Affinity Routing is enabled (i.e. you're in the "new" GICv3/4 mode), it's a programming error to access the memory mapped CPU interface registers.

    Instead you would use the new system registers:

    • ICC_IAR0_EL1
    • ICC_IAR1_EL1

    Notice that there's no "aliased" version of the register in GICv3/4.

    In Legacy mode (i.e. GICv2), the idea was that a read of GICC_IAR would return a different value based on the Grouping of the highest priority pending interrupt, and whether the read of the memory mapped register was Secure or Non-secure.

    You can see this in Table 4-35 of the GICv2 Architecture Specification (ARM IHI 0048B).

    Assuming GICC_CTLR.AckCtl = 0, the behaviour was as follows:

    State
    GICC_IAR readReturned interrupt ID
    Highest priority pending interrupt is Group 1Non-secureID of Group 1 interrupt
    SecureInterrupt ID 1022
    Highest priority pending interrupt is Group 0Non-secureInterrupt ID 1023
    SecureID of Group 0 interrupt
    No pending interruptsNon-secure & SecureInterrupt ID 1023

    Note how we can't get the ID of a Group 1 interrupt from a Secure read of GICC_IAR in the above scenario. This is where the aliased GICC_AIAR is used. This register is an alias of the Non-secure view of GICC_IAR, so that a Secure read of this register is identical to a Non-secure access to GICC_IAR, allowing Secure software to acknowledge Group 1 interrupts.

    In GICv3/4 mode we now instead have ICC_IAR0_EL1 for acknowledging Group 0 interrupts, and ICC_IAR1_EL1 for acknowledging Group 1 interrupts. Because the CPU interface is now inside the processor itself (hence the system registers), the GIC is now "aware" of the current security state of the core.

    If you look at section 3.2.1 "Special INTIDs" of the GICv3/4 Architecture Specification (ARM IHI 0069A), you'll see that there are some new ones and that INTID 1023 has been slightly redefined to be based on the PE's current security state. This ensures that software only gets valid INTIDs for interrupts it can acknowledge, and in the case of EL3 (Secure Monitor) code, the new special INTIDs can tell it whether it needs to perform a world-switch between Non-secure and Secure state.

    So in summary, to answer your questions:

    1. Yes
    2. In the scenario that Secure world software wants to acknowledge the Group 1 interrupt
    3. In GICv2 this register was actually only accessible to Secure accesses - Assuming the GICv3/4 legacy spec is correct, it sounds as if a Non-secure access to GICC_AIAR now effectively behaves as a Non-secure access to GICC_IAR

    I hope that helps,

    Ash.