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 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:
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:
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:
I hope that helps,
Ash.
Thank you Ash Wilding for kind reply..,
it is very clear.