Generic Interrupt Controller versions 3 and 4

Introduction

This page seeks to give a quick reference to the behaviour of the version 3 and 4 GIC, especially relative to version 2. It heavily references [User:Gravaera/Generic Interrrupt Controller], and recommends that page as prior reading.

Version 3 of the GIC specification is no longer separate from the core ARM specification, but as of version 3, the GICv3 is part of the architectural state of the ARM architecture, from ARMv8 and onward. In particular, from ARMv8 onwards, access to the GICC_*, GICV_* and GICH_* groups of registers are provided as ARM architected system registers, and not only as memory-mapped registers. In other words, they are accessible as ARM coprocessors. The GICD_*, GICR_* and GICS_* groups of registers however, are always memory mapped.

On an ARMv7 platform, the GIC is an extension that is not architecturally specified. On ARMv8 platforms, the GIC, if implemented, is architecturally specified.

Another key improvement over GICv2 is that CPUIDs in GICv3 are no longer restricted to a maximum of 8 processor IDs, and so GICv3 and upwards supports the delivery of IRQs to more than 8 Processing Elements (PEs).

Message-Based IRQ support

The ITS is one method of supporting MSI IRQs on ARM platforms that implement the GIC architecture. There are two approaches, and a platform must support only one (GICv3&4 specification, section 6.2):

• The device generates an LPI by writing directly to the Redistributor's GICR_SETLPIR.
• The device generates an LPI via the ITS service, which will generate the LPI on its behalf.

In GICv3 the ITS is optional, one option (ITS vs no-ITS). In GICv4, there must be at least one ITS, in order to support the injection of virtual LPIs into vPEs (so GICv4 must choose the ITS approach, and it does not have the option of using the non-ITS approach).

Locality-based Peripheral IRQ

Support for a new type of IRQ is added from GICv3 onwards: Locality-based Peripheral IRQs (LPIs), which are used for message-based IRQs. LPIs are not routed through the Distributor, but they are routed directly to Redistributors, which are connected directly to PEs. The Distributor manages pin-based IRQs (SPIs, PPIs and SGIs) while the ITS+Redistributors manage MSIs.

LPIs can be generated either by writing to a Redistributor's GICR_SETLPIR, or through the ITS.

LPIs are always edge-triggered. (GICv3&4 specification, section 1.2.1).

Interrupt Translation Service

Note that the configuration of ITS should have no effect on SPIs, SGI, PPIs (GICv3&4 specification, section 6.2: "An ITS has no effect on SGIs, SPIs or PPIs."). Its purpose is confined to generating IRQ signals from in-band bus messages.

For the GIC architecture, ARM devices that support MSI (message-signaled IRQs) are each assigned a DeviceID. Additionally, each MSI IRQ that the device will generate is assigned an EventID. This combination of DeviceID+EventID are used as inputs to the ITS. The ITS then uses the DeviceID to index into its Device Table, and select that device's Interrupt Translation Table (ITT). The EventID is then used to index into the ITS' ITT for that device, and select the pertinent Interrupt Translation Entry (ITE).

Each ITE then indicates a Collection Table (CT) entry, which gives the target Redistributor for a physical MSI IRQ. For GIVc3, if a device has a physical MSI IRQ, and the OS Hypervisor would like to virtualize that IRQ to a Guest VM, the hypervisor must deliver that IRQ as a standard virtual IRQ (Not 100% sure on this yet).

GICv4 also adds support for delivering virtual MSI IRQs. In this case, the ITE indicates a vPEID, which indicates a vPE table entry (and therefore, the physical Redistributor that hosts the target vPE for the virtual MSI).

These tables may seem tedious, and that is because they are; but thankfully they are not exposed to the hypervisor. The hypervisor is required to simply update the global IPL configuration table, and then issue INVALIDATE (INV and INVALL) commands to the ITS machinery (if it exists), so that the ITS can read the new configuration values. It is not possible to directly access the ITS' internal tables (GICv3&4 specification, section 6.2). The hypervisor should also issue a SYNC command to the ITS if it needs to be sure that the INVALIDATE command has completed before execution continues.

Where there is no ITS hardware implemented, the hypervisor performs invalidation of LPI configuration via writes to GICR_INVALLR (invalidate all entries) or GICR_INVLPIR (invalidate single entry).

Caveat: All the ITS' tables are stored in non-secure physical memory. Author's comment: It appears that the entire GIC MSI IRQ architecture is based on routing of MSI IRQs directly to a Redistributor, or indirectly to a Redistributor through an ITS.

References

• [GIC version 3 and 4 specifiction] (Click on the arrow icon next to "Contents" to get a link to the PDF from ARM.)
• [GIC Wiki page]
• [Another Wiki page]