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.

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.

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.

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]